A firehose block cursor fetches blocks of records from the cached result-set at the client-side. When, at the client side, the DataServer processes blocks of records, as opposed to individual records, it implementes the firehose block cursors for faster cursor-processing. For information on Firehose cursors and block cursors, see
Firehose cursors and
Block cursors.
To enable the firehose block cursor, you must enable the firehose cursors and the block cursors. You enable the firehose cursors by enabling the CONNECTION_POOLING option and/or by having available connections when either the PRGRS_CACHE_CONN option is greater than zero or the QUERY-TUNING(SEPARATE-CONNECTION) keyword is added to the query. And, you enable the block cursors by enabling the PRGRS_BLOCK_CURS option and ensuring that there are adequate memory resources to allocate record blocks for the result sets.
CONNECTION_POOLING is enabled by default and the
PRGRS_CACHE_CONN option is non-zero by default. For more information on
CONNECTION_POOLING and
PRGRS_CACHE_CONN option, see
Connectionpooling and
DataServerconnection management.
The
PRGRS_BLOCK_CURS option is also enabled by default. Because of the default enabling of a combination of options, the DataServer session is generally configured to take advantage of firehose block cursors whenever possible. For more information on the
PRGRS_BLOCK_CURS dataserver option, see
DataServeroptions.
The following DataServer operations are eligible for the firehose block cursor implementation:
Note: Prepared statements associated with firehose block cursors are cached on a statement cache that is associated with the managed connection. Statement reuse may decrease based on the recycling of managed connections. To completely disable the prepared statement cache, use the following connection switch: "
-Dsrv PRGRS_PREPCACHE,0". For information about monitoring the statement cache reuse, see
Monitoring cursor and connection use.