pg.ddx.io pgsql-hackers@postgresql.org mailing list archive help / color / mirror / Atom feed From: Andrew Gierth <andrew@tao11.riddles.org.uk>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andreas Karlsson <andreas@proxel.se>
Cc: David Fetter <david@fetter.org>
Cc: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Early WIP/PoC for inlining CTEs
Date: Sun, 27 Jan 2019 13:22:57 +0000
Message-ID: <87fttejl62.fsf@news-spur.riddles.org.uk> (raw )
In-Reply-To: <31065.1548543317@sss.pgh.pa.us >
References: <87sh48ffhb.fsf@news-spur.riddles.org.uk >
<20180725054236.GB17411@fetter.org >
<87bmavfjhy.fsf@news-spur.riddles.org.uk >
<20180725191447.GE17411@fetter.org >
<CAEepm=0MKV3MnR4Dn5RkXsK+RnmHEFitqiG4PcBhXtBK4JOoWw@mail.gmail.com >
<20180727081058.GN17411@fetter.org >
<dccb37dd-2f52-dbd7-a4c4-72a5853f4838@proxel.se >
<e02af96a-3e25-5de4-09a4-a7ebf3452184@proxel.se >
<8810.1542402910@sss.pgh.pa.us >
<d4daf011-01cf-6bf9-3f15-85ae1572e909@proxel.se >
<87r2dxrw1z.fsf@news-spur.riddles.org.uk >
<d0619160-10af-dcc9-4e7d-57845b92570c@proxel.se >
<29ce1707-0dae-ad33-8ab0-7d5226c7dfd3@proxel.se >
<11140.1548454956@sss.pgh.pa.us >
<31065.1548543317@sss.pgh.pa.us >
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
Tom> I was interested to find, while writing the docs, that it's a real
Tom> struggle to invent plausible reasons to write MATERIALIZED given
Tom> the above specification. You pretty much have to have lied to the
Tom> planner, eg by making a volatile function that's not marked
Tom> volatile, before there's a real need for that. Am I missing
Tom> something? If I'm not, then we're in a really good place
Tom> backwards-compatibility-wise, because the new default behavior
Tom> shouldn't break any cases where people weren't cheating.
The cases where the new default will break things are where people used
WITH to force a choice of join order or otherwise constrain the planner
in order to avoid a misplan.
I'm not sure we should nail down the rule that the absence of NOT
MATERIALIZED will mean a multiply-referenced CTE is evaluated once. One
would hope that in the future the planner might be taught to inline or
not in that case depending on cost. I think it makes more sense to say
that we never inline if MATERIALIZED is specified, that we always inline
if NOT MATERIALIZED is specified, and that if neither is specified the
planner will choose (but perhaps note that currently it always chooses
only based on refcount).
--
Andrew (irc:RhodiumToad)
view thread (112+ messages) latest in thread
Message-ID: <87fttejl62.fsf@news-spur.riddles.org.uk>
Permalink: ../87fttejl62.fsf@news-spur.riddles.org.uk/
Also on: postgresql.org/message-id/87fttejl62.fsf@news-spur.riddles.org.uk
copy link · copy postgr.es
reply Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: andrew@tao11.riddles.org.uk, tgl@sss.pgh.pa.us, andreas@proxel.se, david@fetter.org, thomas.munro@enterprisedb.com
Subject: Re: Early WIP/PoC for inlining CTEs
In-Reply-To: <87fttejl62.fsf@news-spur.riddles.org.uk>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox