| From: | Bruno Wolff III <bruno(at)wolff(dot)to> |
|---|---|
| To: | Greg Stark <gsstark(at)mit(dot)edu> |
| Cc: | "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>, Neil Conway <neilc(at)samurai(dot)com>, =?iso-8859-1?q? Pailloncy Jean-Gérard?= <pailloncy(at)ifrance(dot)com>, PostgreSQL Performance <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: slow plan for min/max |
| Date: | 2003-09-09 18:49:54 |
| Message-ID: | 20030909184954.GA14198@wolff.to |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Tue, Sep 09, 2003 at 12:54:04 -0400,
Greg Stark <gsstark(at)mit(dot)edu> wrote:
>
> So what would it take to implement this for "all" aggregates? Where I think
> "all" really just means min(), max(), first(), last().
There can be other aggregates where indexes are helpful. The case of interest
is when functions such that if the new item is contains the current value
of the aggregate then the new value of the aggregate with be that of the
current item. This allows you to skip looking at all of the other items
contained in the current item. Dual problems can also benefit in a similar
manner. In a case where the set is totally ordered by the contains index
(as is the case or max and min) then the problem is even simpler and you
can use the greatest or least element as appropiate.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Swan | 2003-09-09 19:06:56 | Re: slow plan for min/max |
| Previous Message | Josh Berkus | 2003-09-09 17:14:03 | Re: slow plan for min/max |