Re: Early WIP/PoC for inlining CTEs

From: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
To: Andreas Karlsson <andreas(at)proxel(dot)se>
Cc: David Fetter <david(at)fetter(dot)org>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Early WIP/PoC for inlining CTEs
Date: 2018-10-05 00:40:05
Message-ID: 87y3bdckvu.fsf@news-spur.riddles.org.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>>>>> "Andreas" == Andreas Karlsson <andreas(at)proxel(dot)se> writes:

> On 10/03/2018 05:57 PM, David Fetter wrote:
>> Is there any meaningful distinction between "inlining," by which I
>> mean converting to a subquery, and predicate pushdown, which
>> would happen at least for a first cut, at the rewrite stage?

Yes.

Andreas> Sorry, but I do not think I understand your question. The
Andreas> ability to push down predicates is just one of the potential
Andreas> benefits from inlining.

Consider the difference between (in the absence of CTE inlining):

-- inline subquery with no optimization barrier (qual may be pushed down)
select * from (select x from y) s where x=1;

-- inline subquery with optimization barrier (qual not pushed down)
select * from (select x from y offset 0) s where x=1;

-- CTE with materialization
with s as (select x from y) select * from s where x=1;

--
Andrew (irc:RhodiumToad)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2018-10-05 00:54:58 Re: snprintf assert is broken by plpgsql #option dump
Previous Message Michael Paquier 2018-10-05 00:34:42 Re: Segfault when creating partition with a primary key and sql_drop trigger exists