| From: | Bruno Wolff III <bruno(at)wolff(dot)to> |
|---|---|
| To: | "Jim C(dot) Nasby" <decibel(at)decibel(dot)org> |
| Cc: | Mark Kirkwood <markir(at)coretech(dot)co(dot)nz>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: MAX/MIN optimization via rewrite (plus query rewrites |
| Date: | 2004-11-11 14:07:53 |
| Message-ID: | 20041111140753.GB16640@wolff.to |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Nov 11, 2004 at 01:18:05 -0600,
"Jim C. Nasby" <decibel(at)decibel(dot)org> wrote:
> Certainly handling only one case is better than none. I just wanted to
> bring up the multiple aggregate scenario. Also, consider that
>
> SELECT min(a), max(a), min(b), max(c) FROM table
>
> could be optimized as well (into 4 index scans, assuming a, b, and c all
> had indexes).
>
> I don't think any other aggregates are candidates for optimization right
> now, though I guess I could be wrong.
Remember that max and min are a number of aggregates, as each datatype
which have max and min functions have different ones from those used
by other datatypes.
I think someone added boolean aggregates for and and or in version 8.
If so, those can also use indexes in the same way.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Oleg Bartunov | 2004-11-11 14:42:01 | Re: ltree PostgreSQL Module |
| Previous Message | Bruno Wolff III | 2004-11-11 14:00:01 | Re: MAX/MIN optimization via rewrite (plus query rewrites generally) |