Kevin Grittner wrote:
> (3) There is overhead to creating a cursor for a select statement.
> Granted, in my tests it was only about 20 microseconds, but that boosted
> runtime for my simple test case by 3%.
This seems a bit high; what's your query and which driver version are
you using? The current drivers just name the result portal at the
protocol level (which is essentially a FETCH_FORWARD_ONLY cursor, but
not in so many words) and ask for N rows at a time; otherwise, all the
processing should be the same. I'm suprised that the act of naming the
portal and splitting the output into batches adds as much as 20ms to
query execution time..
-O
