From: | Bruno Wolff III <bruno(at)wolff(dot)to> |
---|---|
To: | Ken Geis <kgeis(at)speakeasy(dot)org> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: bad estimates / non-scanning aggregates |
Date: | 2003-08-29 02:51:09 |
Message-ID: | 20030829025109.GD4373@wolff.to |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Thu, Aug 28, 2003 at 17:10:31 -0700,
Ken Geis <kgeis(at)speakeasy(dot)org> wrote:
> The query I want to run is
>
> select stock_id, min(price_date) from day_ends group by stock_id;
The fast way to do this is:
select distinct on (stock_id) stock_id, price_date
order by stock_id, price_date;
> Also, to get the MIN for a given group, not all values of the index need
> to be seen. Must pgsql do a full scan because it treats all aggregates
> in the same way? Are MIN and MAX used often enough to justify special
> treatment, and could that be cleanly implemented? Perhaps the aggregate
> function can request the data in a certain order, be told that it is
> being passed data in a certain order, and return before seeing the
> entire set of data.
Yes, max and min are not treated special so they don't benefit from
indexes. This has been discussed repeatedly in the archives.
From | Date | Subject | |
---|---|---|---|
Next Message | Ken Geis | 2003-08-29 03:00:32 | Re: bad estimates / non-scanning aggregates |
Previous Message | Ken Geis | 2003-08-29 02:50:38 | Re: bad estimates / non-scanning aggregates |