Re: Invalid optimization of VOLATILE function in WHERE clause? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Invalid optimization of VOLATILE function in WHERE clause?
Date
Msg-id 747.1348075597@sss.pgh.pa.us
Whole thread Raw
In response to Re: Invalid optimization of VOLATILE function in WHERE clause?  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Invalid optimization of VOLATILE function in WHERE clause?  (Robert Haas <robertmhaas@gmail.com>)
Re: Invalid optimization of VOLATILE function in WHERE clause?  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> It still seems like awfully weird behavior.

Why?  The WHERE condition relates only to the output of the _stats
subquery, so why shouldn't it be evaluated there, rather than after
the join?

In a green field I might agree that we should de-optimize such cases,
but the problem with doing so is that it would totally destroy
performance for cases in which a user has defined a function that's
actually stable or immutable but they forgot to mark it so.  If
VOLATILE weren't the default marking, such a change wouldn't be so
problematic ... but it is.  Given that the behavior has been like
this since the late stone age, I'm not inclined to change it.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Removal of AcceptInvalidationMessages broke things
Next
From: Tom Lane
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Properly set relpersistence for fake relcache entries.