Re: Optimizing maximum/minimum queries (yet again)

From: Tom Lane
Subject: Re: Optimizing maximum/minimum queries (yet again)
Date: ,
Msg-id: 19475.1113022631@sss.pgh.pa.us
(view: Whole thread, Raw)
In response to: Re: Optimizing maximum/minimum queries (yet again)  (Neil Conway)
Responses: Re: Optimizing maximum/minimum queries (yet again)  (Bruno Wolff III)
List: pgsql-hackers

Tree view

Optimizing maximum/minimum queries (yet again)  (Tom Lane, )
 Re: Optimizing maximum/minimum queries (yet again)  (Bruno Wolff III, )
  Re: Optimizing maximum/minimum queries (yet again)  (Tom Lane, )
   Re: Optimizing maximum/minimum queries (yet again)  (Bruno Wolff III, )
 Re: Optimizing maximum/minimum queries (yet again)  (Bruno Wolff III, )
  Re: Optimizing maximum/minimum queries (yet again)  (Tom Lane, )
 Re: Optimizing maximum/minimum queries (yet again)  (Bruno Wolff III, )
  Re: Optimizing maximum/minimum queries (yet again)  (Tom Lane, )
 Re: Optimizing maximum/minimum queries (yet again)  (Mark Kirkwood, )
 Re: Optimizing maximum/minimum queries (yet again)  (Neil Conway, )
  Re: Optimizing maximum/minimum queries (yet again)  (Tom Lane, )
   Re: Optimizing maximum/minimum queries (yet again)  (Neil Conway, )
    Re: Optimizing maximum/minimum queries (yet again)  (Tom Lane, )
     Re: Optimizing maximum/minimum queries (yet again)  (Bruno Wolff III, )
      Re: Optimizing maximum/minimum queries (yet again)  (Tom Lane, )

Neil Conway <> 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:

From: Tom Lane
Date:
Subject: Re: Optimizing maximum/minimum queries (yet again)
From: Tom Lane
Date:
Subject: Re: [GENERAL] table and column information from cursor?