Re: Call for objections: simplify stable functions during estimation - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Call for objections: simplify stable functions during estimation
Date
Msg-id 26844.1100027089@sss.pgh.pa.us
Whole thread Raw
In response to Re: Call for objections: simplify stable functions during estimation  (Robert Treat <xzilla@users.sourceforge.net>)
List pgsql-hackers
Robert Treat <xzilla@users.sourceforge.net> writes:
> On Tuesday 09 November 2004 11:28, Tom Lane wrote:
>> (One of the potential objections went away when
>> we started enforcing that stable functions don't have side-effects.)

> Since we know people will be calling volatile functions inside stable 
> functions (see thread from last week if you need a refresher as to why) is 
> there any serious negative side-effect in those cases?

If you are making an end-run around the rule, IMHO it's up to you to make
sure that the behavior of the function is sane.  In practice, the
planner is only going to be estimating values for functions that appear
in WHERE/GROUP BY/HAVING clauses, and anyone who puts a function with
real side-effects in such places is in deep trouble anyway.

The real bottom line here is that it's better to take the current value
of the function as the planner estimate than to fall back to completely
default selectivity estimates.  You can doubtless invent scenarios where
this is wrong, but they are far outweighed by cases where it is right.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Treat
Date:
Subject: Re: Call for objections: simplify stable functions during estimation
Next
From: Tom Lane
Date:
Subject: A modest proposal: get rid of GUC's USERLIMIT variable category