By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
437,558 Members | 1,060 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 437,558 IT Pros & Developers. It's quick & easy.

DB2 UDB LUW: query, cursor types and optimization

P: n/a
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

Nov 12 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
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
Nov 12 '05 #2

P: n/a
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

Nov 12 '05 #3

P: n/a
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
Nov 12 '05 #4

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

Bernard Dhooghe

Nov 12 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.