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

From Simon Riggs
Subject Re: Call for objections: simplify stable functions
Date
Msg-id 1100021294.4442.152.camel@localhost.localdomain
Whole thread Raw
In response to Call for objections: simplify stable functions during estimation  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, 2004-11-09 at 16:28, Tom Lane wrote:
> Awhile back, there was some discussion about pre-folding now() and
> related functions when the planner is trying to estimate selectivities.
> This would allow reasonable plans to be made for cases like
>     WHERE moddate >= current_date - 10;
> without having to indulge in any crude hacks with mislabeled wrapper
> functions, such as you can find all too often in the archives :-(
> 
> I was a bit hesitant about it at the time because I wasn't sure of all
> the implications; but I've looked the idea over again, and as far as I
> can see it's reasonable to pre-fold *all* stable functions when deriving
> statistical estimates.  (One of the potential objections went away when
> we started enforcing that stable functions don't have side-effects.)
> 
> The infrastructure for this is already there, because of Oliver Jowett's
> previous work to teach eval_const_expressions() whether it's folding
> the expression "for real" or just for estimation; it's basically a one
> line change to treat stable functions differently in the two cases.
> 
> I know it's a bit late in the cycle, but I'd like to go ahead and make
> this change for 8.0.  Objections?

None. IMHO Poor performance is a valid bug that must be addressed in the
beta cycle. We've chased out most of the functional deficiencies, now
its time to concentrate on the performance ones.

-- 
Best Regards, Simon Riggs



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: debugging PostgreSQL
Next
From: "Marc G. Fournier"
Date:
Subject: Re: Call for objections: simplify stable functions during