Re: [HACKERS] CTE inlining - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] CTE inlining
Date
Msg-id 9846.1493912210@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] CTE inlining  (Serge Rielau <serge@rielau.com>)
Responses Re: [HACKERS] CTE inlining  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
List pgsql-hackers
Serge Rielau <serge@rielau.com> writes:
>> On May 4, 2017, at 3:02 AM, Gavin Flower <GavinFlower@archidevsys.co.nz> wrote:
>> On 30/04/17 16:28, Tom Lane wrote:
>>> There's already a pretty large hill to climb here in the way of
>>> breaking peoples' expectations about CTEs being optimization
>>> fences.  Breaking the documented semantics about CTEs being
>>> single-evaluation seems to me to be an absolute non-starter.

> Are you worried about semantics or performance?
> With proper detection of mutating functions and snapshot isolation I do not see how a user would detect “lack of”
singleevaluation. 

I do not think a user will have any trouble "detecting" what we did
if his query runs for two hours, rather than two minutes, because we
executed some expensive function 100 times rather than the one time
he expected it to run.

Now you could argue that that's user error because he should have
marked the expensive function with a sufficiently high cost to
discourage us from flattening the CTE.  But not everyone will have
done that (and I'm not sure we have any planner smarts that would
respond to such cases anyway).  So what I'm saying is that if you're
promising there will be no visible bad consequences, you're wrong.

It may be worth breaking some peoples' queries to make other peoples'
queries faster, but I think we need to tread pretty carefully there.
And we definitely can't change any case where there would be visible
semantic differences.
        regards, tom lane



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()
Next
From: Dmitriy Sarafannikov
Date:
Subject: Re: [HACKERS] [PROPOSAL] Use SnapshotAny in get_actual_variable_range