Serge Rielau <se...@rielau.com> writes:
>> On May 4, 2017, at 3:02 AM, Gavin Flower <gavinflo...@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” single evaluation.
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
