Bruce Momjian <pgman@candle.pha.pa.us> writes:
> So it forces our LIMIT optimization, without limiting the number of rows
> returned. That seems to be of questionable value. The only value I can
> see for it is for CURSOR queries but I don't think we can start
> returning rows from even a cursor until the entire query is done
> executing.
Not so at all. However, CURSORs are already optimized on the assumption
that not all the rows will actually get fetched.
Awhile back, someone (Hiroshi, I think) suggested that there should be
a user-accessible SET variable to control the percentage of rows of a
cursor that the optimizer would optimize for fetching. (Right now,
IIRC, the estimate is fixed at 10%.) This is a good idea, and quite
trivial to do, but no one got around to it yet. I think that such a
variable would answer this issue fully, except perhaps for not
duplicating the nonstandard syntax used by the other products.
Do they really all use exactly the same syntax for this?
regards, tom lane
