Re: Optimizing maximum/minimum queries (yet again)

From: Tom Lane
Subject: Re: Optimizing maximum/minimum queries (yet again)
Date: ,
Msg-id: 18864.1113017873@sss.pgh.pa.us
(view: Whole thread, Raw)
In response to: 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, )

Bruno Wolff III <> writes:
> Thinking about the case for NULLs some more, I am wondering if you are
> going to treat aggregates with strict state functions different than
> those that don't?

We only intend this to support MAX and MIN.  If you're inventing an
aggregate that doesn't play exactly by those rules, you don't get to
take advantage of the optimization.
        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?