| From: | Bruno Wolff III <bruno(at)wolff(dot)to> |
|---|---|
| To: | Thomas Swan <tswan(at)idigx(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>, Neil Conway <neilc(at)samurai(dot)com>, 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 19:34:28 |
| Message-ID: | 20030909193428.GA15389@wolff.to |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Tue, Sep 09, 2003 at 14:06:56 -0500,
Thomas Swan <tswan(at)idigx(dot)com> wrote:
>
> Would it be possible to rewrite min and max at the parser level into a
> select/subselect (clause) condition ( repeat condition ) order by
> (clause ) descending/ascending limit 1 and thereby avoiding the
> penalties of altering the default aggregate behavior? Would it yield
> anything beneficial?
That isn't always going to be the best way to do the calculation. If there
are other aggregates or if the groups are small, doing things the normal
way (and hash aggregates in 7.4 will help) can be faster.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chris Huston | 2003-09-09 23:49:02 | Reading data in bulk - help? |
| Previous Message | Thomas Swan | 2003-09-09 19:06:56 | Re: slow plan for min/max |