The DataServer caches results sets from a MS SQL Server data source to enhance performance when using block cursors. It caches as much data as fits in its allocated cache size. When using firehose and/or lookahead calls, the allocations are made to fit the size of the result set. Depending on what kind of cursor a query is using, the DataServer caches row identifiers or records:

  • Standard cursors — The DataServer caches row identifiers (PROGRESS_RECID column or other unique index) for the results set. If you use the PROGRESS_RECID, each identifier requires 8 bytes of cache, therefore, a results set of 100 records requires 800 bytes of cache. If you do not use the PROGRESS_RECID field, the cache size might be greater if the selected unique index has a greater length than this field.
  • Lookahead cursors — The DataServer caches complete records or partial records as specified by a field list. It uses the maximum length allowed for a row as defined in the MS SQL Server data source to calculate the record length, not the actual contents of the record. In addition to the defined row length, the record consists of a row identifier field; therefore, a row with a defined maximum length of 100 bytes requires 108 bytes of cache. If a column is longer than 256 bytes, the DataServer refetches it.

In the case of joins, each record in the cache is a result of the fields selected in the join. In addition to the record, there is a row identifier field (8 bytes) for each table involved in the join. For example, a three-way join adds 24 bytes to the cache for each record.

You can affect the performance of a query by controlling the size of the cache when lookahead cursors are used. As queries generate different results, they benefit from different cache sizes. Generally, the larger the cache, the faster the performance. However, you must balance cache size against other memory requirements for your system. Consider also that continually adjusting cache size in an application might decrease performance as each adjustment requires the DataServer to make several calls to the data source.

To determine the optimal cache size for a query, experiment with different values for CACHE-SIZE and use DEBUG EXTENDED to generate cursor statistics in the dataserv.lg file that you can examine. Aim for minimal cursor activity. The following example sets an optimal cache size for a particular query against the sports database:

FOR EACH customer, EACH order OF customer WHERE order.ordnum GT 20
  QUERY-TUNING(CACHE-SIZE 20 DEBUG EXTENDED):