IGNITE-19378 Documentation: Improve docs related to lazy loading - Fixes

 apache#10671.

Signed-off-by: Aleksey Plekhanov <[email protected]>

docs/_docs/SQL/JDBC/jdbc-client-driver.adoc

@@ -139,16 +139,6 @@ However, in cases when you need transactional syntax to work (even without trans
 
 |`false`
 
-|`lazy`
-
-|Lazy query execution.
-
-By default, Ignite attempts to fetch the whole query result set to memory and send it to the client. For small and medium result sets, this provides optimal performance and minimizes the duration of internal database locks, thus increasing concurrency.
-
-However, if the result set is too big to fit in the available memory, it can lead to excessive GC pauses and even `OutOfMemoryError` errors. Use this flag to tell Ignite to fetch the result set lazily, thus minimizing memory consumption at the cost of a moderate performance hit.
-
-|`false`
-
 |`skipReducerOnUpdate`
 
 |Enables server side update feature.

docs/_docs/SQL/JDBC/jdbc-driver.adoc

@@ -136,12 +136,6 @@ See the link:security/authentication[Authentication] and link:sql-reference/ddl#
 | Whether to use `TCP_NODELAY` option.
 |`true`
 
-|`lazy`
-|Lazy query execution.
-By default, Ignite attempts to get and load the whole query result set into memory and then send it to the client. For small and medium result sets, this provides optimal performance and minimizes the duration of internal database locks, thus increasing concurrency.
-However, if the result set is too big to fit in the available memory, then it can lead to excessive GC pauses and even 'OutOfMemoryError's. Use this flag to tell Ignite to fetch the result set lazily, thus minimizing memory consumption at the cost of a moderate performance hit.
-|`false`
-
 |`skipReducerOnUpdate`
 |Enables server side updates.
 When Ignite executes a DML operation, it fetches all the affected intermediate rows and sends them to the query initiator (also known as reducer) for analysis. Then it prepares batches of updated values to be sent to remote nodes.

docs/_docs/SQL/ODBC/connection-string-dsn.adoc

@@ -99,12 +99,6 @@ a primary or affinity key, then Ignite makes significant performance and network
  on each node participating in the query.
 |`false`
 
-|`LAZY`
-|Lazy query execution.
-By default, Ignite attempts to fetch the whole query result set to memory and send it to the client. For small and medium result sets, this provides optimal performance and minimize duration of internal database locks, thus increasing concurrency.
-However, if the result set is too big to fit in the available memory, then it can lead to excessive GC pauses and even `OutOfMemoryError` errors. Use this flag to tell Ignite to fetch the result set lazily, thus minimizing memory consumption at the cost of a moderate performance hit.
-|`false`
-
 |`SKIP_REDUCER_ON_UPDATE`
 |Enables server side update feature.
 When Ignite executes a DML operation, first, it fetches all the affected intermediate rows for analysis to the query initiator (also known as reducer), and only then prepares batches of updated values that will be sent to remote nodes.

docs/_docs/perf-and-troubleshooting/sql-tuning.adoc

@@ -78,12 +78,13 @@ with 100+ columns may perform worse than expected.
 
 == Lazy Loading
 
-By default, Ignite attempts to load the whole result set to memory and send it back to the query initiator (which is
-usually your application). This approach provides optimal performance for queries of small or medium result sets.
-However, if the result set is too big to fit in the available memory, it can lead to prolonged GC pauses and even `OutOfMemoryError` exceptions.
+By default, Ignite will set Lazy Loading enabled, this will minimize memory consumption at the cost of moderate performance degradation.
 
-To minimize memory consumption, at the cost of a moderate performance hit, you can load and process the result sets
-lazily by passing the `lazy` parameter to the JDBC and ODBC connection strings or use a similar method available for Java, .NET, and C++ APIs:
+Otherwise, Ignite attempts to load the whole result set to memory and send it back to the query initiator (which is usually your application). This approach provides optimal performance for queries of small or medium result sets, and minimizes the duration of internal database locks, thus increasing concurrency. 
+
+WARNING, if the result set is too big to fit in the available memory, it can lead to prolonged GC pauses and even `OutOfMemoryError` exceptions. This property is deprecated since Ignite 2.15.0.
+
+To change the default behavior: 
 
 [tabs]
 --
@@ -94,20 +95,20 @@ tab:Java[]
 SqlFieldsQuery query = new SqlFieldsQuery("SELECT * FROM Person WHERE id > 10");
 
 // Result set will be loaded lazily.
-query.setLazy(true);
+query.setLazy(false);
 ----
 tab:JDBC[]
 [source,sql]
 ----
-jdbc:ignite:thin://192.168.0.15?lazy=true
+jdbc:ignite:thin://192.168.0.15?lazy=false
 ----
 tab:C#/.NET[]
 [source,csharp]
 ----
 var query = new SqlFieldsQuery("SELECT * FROM Person WHERE id > 10")
 {
     // Result set will be loaded lazily.
-    Lazy = true
+    Lazy = false
 };
 ----
 tab:C++[]