Re: LIMIT Optimization

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: "alexandre paes :: aldeia digital" <alepaes(at)aldeiadigital(dot)com(dot)br>, pgsql-sql(at)postgresql(dot)org
Subject: Re: LIMIT Optimization
Date: 2002-01-25 17:52:11
Message-ID: 26776.1011981131@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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

In response to

Responses

Browse pgsql-sql by date

  From Date Subject
Next Message Bruce Momjian 2002-01-25 17:54:57 Re: LIMIT Optimization
Previous Message Bruce Momjian 2002-01-25 17:32:53 Re: LIMIT Optimization