From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Kris Jurka <books(at)ejurka(dot)com>, Bruce Momjian <momjian(at)svr1(dot)postgresql(dot)org>, pgsql-committers(at)postgresql(dot)org |
Subject: | Re: pgsql: Remove item, not sure what it refers to: |
Date: | 2005-04-25 13:52:02 |
Message-ID: | 20050425135202.GG27470@ns.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
* Bruce Momjian (pgman(at)candle(dot)pha(dot)pa(dot)us) wrote:
> Thanks, TODO item readded with a clearer description:
>
> * Allow ORDER BY ... LIMIT 1 to select high/low value without sort or
> index using a sequential scan for highest/lowest values
>
> Right now, if no index exists, ORDER BY ... LIMIT 1 requires we sort
> all values to return the high/low value. Instead The idea is to do a
> sequential scan to find the high/low value, thus avoiding the sort.
Could we take this perhaps a step further and consider things like
'LIMIT 10' and come up with an approximate point where the trade-off
exists? Actually, thinking about this a minute more perhaps there isn't
even a trade-off to be made... What you're suggesting is basically a
size-of-1 temporary memory structure for the 'sort'. Isn't there
already a memory structure used to perform the sorting though? Could it
be adjusted such that it's of a fixed size when 'LIMIT' is given, as
above?
Just some thoughts, while I think the specific 'LIMIT 1' case is
probably pretty common I think the 'LIMIT 10' or 'LIMIT 50' (or however
many you want to display on the webpage...) is a pretty common use case
too and it sounds like we could improve those too with this mechanism.
Thoughts?
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2005-04-25 13:57:07 | Re: pgsql: Remove item, not sure what it refers to: |
Previous Message | Bruce Momjian | 2005-04-25 13:05:47 | Re: pgsql: Remove item, not sure what it refers to: |