On Fri, Jun 21, 2013 at 04:12:32PM +0200, Andres Freund wrote: > On 2013-06-21 09:51:05 -0400, Noah Misch wrote: > > On Fri, Jun 21, 2013 at 09:20:21AM +0000, Albe Laurenz wrote:
> > Even if you could skip it, queries with expensive > > constant expressions would notice the performance loss. The situations > > helped > > by a change like this are too marginal to accept that cost. > > I have to say, that argument doesn't excite me mu8ch. It's not like we > don't want to do the constant expression evaluation at all anymore. Just > not inside CASE WHEN blocks which already are barring some optimizations > anyway... Sure, it's a narrow loss. Before introducing a new narrow loss to fix an existing one, we should consider which loss hurts more. Offhand, I sympathize with the folks who would lose performance more than with the folks who want to write the sorts of expressions under consideration. > > Would it work to run eval_const_expressions() lazily on THEN clauses? The > > plan-time eval_const_expressions() would not descend to them. The first > > ExecEvalCase() to use a given THEN clause would run eval_const_expressions() > > before proceeding. > > Ugh. Doesn't sound nice. Would you elaborate? > > I question whether real applications care. It's important to have CASE > > usable > > for avoiding data-dependent errors, but what's the use of including in your > > query an expression that can do nothing but throw an error? Does anyone > > have > > a real-world example? Perhaps some generated-query scenario. > > It doesn't need to be an actual constant. Something that evaluates to > the value at plan time is enough: > PREPARE foo AS SELECT CASE WHEN (SELECT $1::int)=0 THEN 0 ELSE 1/$1::int END; > EXECUTE foo(0); > Now, that example only crashes because one place uses (SELECT $1) and > the other doesn't, but... Not the "real-world" I was hoping for, but fair enough. "Crash" in this context means "raise an error", right? -- Noah Misch EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
