Re: Optimizing maximum/minimum queries (yet again)

From: Tom Lane
Subject: Re: Optimizing maximum/minimum queries (yet again)
Date: ,
Msg-id: 19604.1113024309@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:
> Tom Lane <> wrote:
>> 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 ...

> I would expect that the sequential plan would be better for a volatile
> where clause since you are going to execute it for every row anyway.

Well, no, wait a minute.  We have never promised that we would
physically evaluate every volatile function at every table row.
What we promise is that we do not assume-without-proof that the
function's value will be the same at every table row.  I don't see
where this optimization breaks that promise.

Obviously, we do make such an assumption for WHERE clauses that actually
get taken into the indexscan condition.  But we already check volatility
before considering a clause as a possible indexscan condition.  The
question here is whether we have to reject the optimization if there are
additional WHERE clauses, not directly related to the proposed
indexscan, that contain volatile functions.  I'm not seeing the argument
that says we must do that.
        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?