From: | Thomas Swan <tswan(at)idigx(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "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:06:56 |
Message-ID: | 3F5E24D0.4040309@idigx.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Tom Lane wrote:
>"scott.marlowe" <scott(dot)marlowe(at)ihs(dot)com> writes:
>
>
>>On Mon, 8 Sep 2003, Neil Conway wrote:
>>
>>
>>>As was pointed out in a thread a couple days ago, MIN/MAX() optimization
>>>has absolutely nothing to do with MVCC. It does, however, make
>>>optimizing COUNT() more difficult.
>>>
>>>
>
>
>
>>Not exactly. While max(id) is easily optimized by query replacement,
>>more complex aggregates will still have perfomance issues that would not
>>be present in a row locking database. i.e. max((field1/field2)*field3) is
>>still going to cost more to process, isn't it?
>>
>>
>
>Er, what makes you think that would be cheap in any database?
>
>Postgres would actually have an advantage given its support for
>expressional indexes (nee functional indexes). If we had an optimizer
>transform to convert MAX() into an index scan, I would expect it to be
>able to match up max((field1/field2)*field3) with an index on
>((field1/field2)*field3).
>
>
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?
From | Date | Subject | |
---|---|---|---|
Next Message | Bruno Wolff III | 2003-09-09 19:34:28 | Re: slow plan for min/max |
Previous Message | Bruno Wolff III | 2003-09-09 18:49:54 | Re: slow plan for min/max |