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: <20181011163952.emtpcrzkpselhupj@alvherre.pgsql>
References: <20181011163952.emtpcrzkpselhupj@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@2ndquadrant.com>
	message dated "Thu, 11 Oct 2018 13:39:52 -0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <5748.1539276324.1@sss.pgh.pa.us>
Date: Thu, 11 Oct 2018 12:45:24 -0400
Message-ID: <5749.1539276324@sss.pgh.pa.us>
Precedence: bulk

Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> On 2018-Oct-11, Tom Lane wrote:
>> I have been fooling around with a patch to allow pull-up of sub-selects
>> that lack any FROM, along the lines discussed in
>> https://www.postgresql.org/message-id/15944.1521127664@sss.pgh.pa.us
>> I find that it is smart enough to reduce that EXISTS to a plain
>> expression, yielding
>> 
>>                     QUERY PLAN                     
>> ----------------------------------------------------
>> Subquery Scan on tenk1_vw_sec
>>   ->  Index Only Scan using tenk1_unique1 on tenk1
>>         Index Cond: (unique1 = 0)
>> (3 rows)

> Hmm, I have the feeling that this would nullify some tests in
> partition_prune also, which IIRC pretend to invoke runtime pruning with
> things like "WHERE partcol = (select 1)".

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.

			regards, tom lane