Re: Optimizing maximum/minimum queries (yet again)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Optimizing maximum/minimum queries (yet again)
Дата
Msg-id 19475.1113022631@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Optimizing maximum/minimum queries (yet again)  (Neil Conway <neilc@samurai.com>)
Ответы Re: Optimizing maximum/minimum queries (yet again)  (Bruno Wolff III <bruno@wolff.to>)
Список 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 по дате отправления:

Предыдущее
От: Neil Conway
Дата:
Сообщение: Re: Optimizing maximum/minimum queries (yet again)
Следующее
От: Bruno Wolff III
Дата:
Сообщение: Re: Optimizing maximum/minimum queries (yet again)