| 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: | Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, "alexandre paes :: aldeia digital" <alepaes(at)aldeiadigital(dot)com(dot)br>, pgsql-sql(at)postgresql(dot)org |
| Subject: | Re: LIMIT Optimization |
| Date: | 2002-01-27 03:59:15 |
| Message-ID: | 25891.1012103955@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:
> I am confused. I thought we already did optimization for LIMIT that
> assumed you only wanted a few values. Is there something we are missing
> there?
Yeah, he was proposing an alternative implementation of sorting that
would win in a scenario like
SELECT ... ORDER BY foo LIMIT <something small>
If you have an index on foo then there's no problem, but if you're
forced to do an explicit sort then the system does a complete sort
before you can get any data out. If the limit is small enough you
can instead do a one-pass "select top N" scan.
Note that this is only workable in the non-cursor case, where you
know the limit for sure.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | pgsql | 2002-01-27 04:04:48 | options for no multiple rows? |
| Previous Message | Bruce Momjian | 2002-01-27 03:40:07 | Re: update syntax |