From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
cc: Robert Haas <robertmhaas@gmail.com>,
        Jeevan Chalke <jeevan.chalke@enterprisedb.com>,
        pgsql-hackers@lists.postgresql.org,
        David Rowley <david.rowley@2ndquadrant.com>
Subject: Re: Soon-to-be-broken regression test case
In-reply-to: <20181011165251.k7ggwmvmlfjv33gr@alvherre.pgsql>
References: <20181011165251.k7ggwmvmlfjv33gr@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@2ndquadrant.com>
	message dated "Thu, 11 Oct 2018 13:52:51 -0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <8264.1539278351.1@sss.pgh.pa.us>
Date: Thu, 11 Oct 2018 13:19:11 -0400
Message-ID: <8265.1539278351@sss.pgh.pa.us>
Precedence: bulk

Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> On 2018-Oct-11, Tom Lane wrote:
>> Hm, I'm not seeing any regression test result changes there.  However,
>> if you're just executing queries and not EXPLAIN'ing them, it's possible
>> something unwanted is happening under the hood.

> Hmm, no, the explains are there.  Here's one example -- maybe your new
> planner smarts do not change these plans for some reason

Oh, I see --- these are just "scalar-result sub-SELECTs", not
sub-select-in-FROM, so they never get into the join tree to begin with.
WHERE EXISTS is an exception because we attempt to translate it to a
JOIN_SEMI join, exposing an opportunity for subquery pullup.

			regards, tom lane