From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Neil Conway <neilc(at)samurai(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Optimizing maximum/minimum queries (yet again) |
Date: | 2005-04-09 04:57:11 |
Message-ID: | 19475.1113022631@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Neil Conway <neilc(at)samurai(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-04-09 05:25:09 | Re: Optimizing maximum/minimum queries (yet again) |
Previous Message | Neil Conway | 2005-04-09 04:48:40 | Re: Optimizing maximum/minimum queries (yet again) |