From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Gierth <andrew@tao11.riddles.org.uk>
cc: Michael Paquier <michael@paquier.xyz>,
        Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
        Robert Haas <robertmhaas@gmail.com>,
        Andreas Karlsson <andreas@proxel.se>,
        Andres Freund <andres@anarazel.de>,
        Thomas Munro <thomas.munro@enterprisedb.com>,
        David Fetter <david@fetter.org>,
        Pg Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Early WIP/PoC for inlining CTEs
In-reply-to: <87d0o970th.fsf@news-spur.riddles.org.uk>
References: <20190111190403.77ye7m5mxypxsf4l@alap3.anarazel.de>
 <CA+TgmobVMPX1wJxPaRQ=FZBzp-AQ=JWK=bzxztqwj=MsOsrnrA@mail.gmail.com>
 <00818be9-2f63-f584-efcd-d97ee0662905@proxel.se>
 <CA+TgmoapASa3RQi=DuSikPoPF4363czSD8KxbOxsfW5XmO3WpQ@mail.gmail.com>
 <5715d93e-6ebc-be17-c2c3-56a873100a38@proxel.se>
 <29576.1548084476@sss.pgh.pa.us>
 <CA+TgmoYZYj8eLdV9AcROtmPW4AJA7ANh3xQh7BcafaPfCnmv+g@mail.gmail.com>
 <12408.1548707732@sss.pgh.pa.us>
 <c16909ed-0789-5199-f315-!5433d83a0026@2ndquadrant.com>
 <32184.1548713132@sss.pgh.pa.us> <20190129045158.GD3121@paquier.xyz>
 <17787.1548791564@sss.pgh.pa.us> <4591.1549134061@sss.pgh.pa.us>
 <87d0o970th.fsf@news-spur.riddles.org.uk>
Comments: In-reply-to Andrew Gierth <andrew@tao11.riddles.org.uk>
	message dated "Sun, 03 Feb 2019 08:14:44 +0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1444.1549745572.1@sss.pgh.pa.us>
Date: Sat, 09 Feb 2019 15:52:52 -0500
Message-ID: <1445.1549745572@sss.pgh.pa.us>
Precedence: bulk

Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
>  Tom> After further reflection I really don't like Andrew's suggestion
>  Tom> that we not document the rule that multiply-referenced CTEs won't
>  Tom> be inlined by default. That would be giving up the principle that
>  Tom> WITH calculations are not done multiple times by default, and I
>  Tom> draw the line at that. It's an often-useful behavior as well as
>  Tom> one that's been documented from day one, so I do not accept the
>  Tom> argument that we might someday override it on the basis of nothing
>  Tom> but planner cost estimates.

> The case that springs to mind is when a CTE with grouping is then joined
> multiple times in the main query with different conditions. If the
> planner is able to deduce (e.g. via ECs) that restrictions on grouped
> columns can be pushed into the CTE, then inlining the CTE multiple times
> might be a significant win. But if that isn't possible, then inlining
> multiple times might be a significant loss.

Sure, but this is exactly the sort of situation where we should offer
a way for the user to force either decision to be made.  I think it's
very unlikely that we'll ever be in a position to make a realistic
cost-based decision for that.  Actually planning it out both ways would
be horrendously expensive (and probably none too reliable anyway, given
how shaky ndistinct estimates tend to be); and we certainly don't have
enough info to make a smart choice without doing that.

			regards, tom lane