Re: Optimizing maximum/minimum queries (yet again) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Optimizing maximum/minimum queries (yet again)
Date
Msg-id 19475.1113022631@sss.pgh.pa.us
Whole thread Raw
In response to Re: Optimizing maximum/minimum queries (yet again)  (Neil Conway <neilc@samurai.com>)
Responses Re: Optimizing maximum/minimum queries (yet again)  (Bruno Wolff III <bruno@wolff.to>)
List pgsql-hackers
Neil Conway <neilc@samurai.com> writes:
> Hmm; what about
>      SELECT min(x), min(x) FROM tab WHERE random() > 0.5;
> Applying the optimization would mean the two min(x) expressions would 
> likely be different, which seems rather weird.

Actually not: my expectation is that identical aggregate calls will get
folded into one subplan.  This is what happens now (when you call min(x)
twice it's computed just once) and the subplan mechanism already has the
infrastructure needed to let us keep doing it.  I feel we need to be
able to do this in order to justify the assumption that evaluating each
aggregate separately is OK from the efficiency standpoint.

>> Still, if it makes you feel at all uncomfortable, we can just refuse
>> the optimization in such cases.

> I'd say that's probably safest.

I don't have a problem with that, but I haven't quite convinced myself
that we need to expend the cycles to check for it, either ...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Neil Conway
Date:
Subject: Re: Optimizing maximum/minimum queries (yet again)
Next
From: Bruno Wolff III
Date:
Subject: Re: Optimizing maximum/minimum queries (yet again)