From: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
---|---|
To: | David Fetter <david(at)fetter(dot)org> |
Cc: | Andreas Karlsson <andreas(at)proxel(dot)se>, 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-06 02:48:02 |
Message-ID: | 87woqvaj1w.fsf@news-spur.riddles.org.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>>>>> "David" == David Fetter <david(at)fetter(dot)org> writes:
>> 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;
David> ...and doesn't need to materialize all of y,
>> -- 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;
David> while both of these do.
The non-CTE one has to _evaluate_ the whole of the "s" subquery, but it
doesn't have to actually store the result, whereas the CTE version needs
to put it all in a tuplestore and read it back.
--
Andrew (irc:RhodiumToad)
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-10-06 02:58:37 | Re: Performance improvements for src/port/snprintf.c |
Previous Message | Alvaro Herrera | 2018-10-06 02:27:59 | Re: Assertion failure with ALTER TABLE ATTACH PARTITION with log_min_messages >= DEBUG1 |