DB2 UDB LUW: query, cursor types and optimization

[Bernard Dhooghe]

To retrieve data from a query where multiple rows can be returned, a
cursor can be used.

Different programming interface exist for cursors: embedded SQL, CLI,
SQL PL, SQLJ, JDBC.

I we look at the CLI interface, as a statement is first prepared in CLI
before a cursor is associated with it, the cursor attributes are not
known at prepare time. Does it mean that the query path for retrieving
rows is not dependent of the cursor attributes in DB2 UDB LUW? Is there
a second "optimization" step to choose the way the rows returned by the
query will be used by the cursor? Example: the query "select
primary_key from table order by primary_key" can retrieve date directly
from the index part and this could be passed as is directly to the
cursor.

Bernard Dhooghe

[Serge Rielau]

Bernard Dhooghe wrote:

To retrieve data from a query where multiple rows can be returned, a
cursor can be used.

Different programming interface exist for cursors: embedded SQL, CLI,
SQL PL, SQLJ, JDBC.

I we look at the CLI interface, as a statement is first prepared in CLI
before a cursor is associated with it, the cursor attributes are not
known at prepare time. Does it mean that the query path for retrieving
rows is not dependent of the cursor attributes in DB2 UDB LUW? Is there
a second "optimization" step to choose the way the rows returned by the
query will be used by the cursor? Example: the query "select
primary_key from table order by primary_key" can retrieve date directly
from the index part and this could be passed as is directly to the
cursor.

Bernard Dhooghe

I'm not clear I follow you on that one.
The ORDER BY clause is part of the query.
There is only one compilation/optimization of the cursor.
Can you give a more complete example?

Cheers
Serge
--
Serge Rielau
DB2 SQL Compiler Development
IBM Toronto Lab

[Bernard Dhooghe]

Let us take as example:

select * from mytable order by primary_key fetch first 1000 rows only
optimize for 1 row

When will the access plan be choosen for this query?

Will it be at prepare time (taken the example of the CLI interface)
(one compilation/optimization step, being it SQLJ, JDBC, CLI, ...), or
at first fetch time, when all attributes associated with the cursor
(read-only or not, scroll or not, keyset or not) are known, wich could
influence the path decision and how the data will be materialized for
the application?
Bernard Dhooghe

[Serge Rielau]

Bernard Dhooghe wrote:

Let us take as example:

select * from mytable order by primary_key fetch first 1000 rows only
optimize for 1 row

When will the access plan be choosen for this query?

Will it be at prepare time (taken the example of the CLI interface)
(one compilation/optimization step, being it SQLJ, JDBC, CLI, ...), or
at first fetch time, when all attributes associated with the cursor
(read-only or not, scroll or not, keyset or not) are known, wich could
influence the path decision and how the data will be materialized for
the application?

The cursor is compiled at OPEN. Presumably all these attributes are set
by the time you do OPEN.

Cheers
Serge

--
Serge Rielau
DB2 SQL Compiler Development
IBM Toronto Lab

[Bernard Dhooghe]

Thank you Serge, clarifies difference between prep and access plan
build step (for dynamic programming interface).

Bernard Dhooghe