From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>,
        Jeevan Chalke <jeevan.chalke@enterprisedb.com>
cc: pgsql-hackers@lists.postgresql.org
Subject: Soon-to-be-broken regression test case
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <5394.1539275668.1@sss.pgh.pa.us>
Date: Thu, 11 Oct 2018 12:34:28 -0400
Message-ID: <5395.1539275668@sss.pgh.pa.us>
Precedence: bulk

The last test case in select_parallel.sql, added in commit dc1057fc,
currently generates a plan like this:

CREATE VIEW tenk1_vw_sec WITH (security_barrier) AS SELECT * FROM tenk1;
EXPLAIN (COSTS OFF)
SELECT 1 FROM tenk1_vw_sec WHERE EXISTS (SELECT 1 WHERE unique1 = 0);
                            QUERY PLAN                             
-------------------------------------------------------------------
 Subquery Scan on tenk1_vw_sec
   Filter: (alternatives: SubPlan 1 or hashed SubPlan 2)
   ->  Gather
         Workers Planned: 4
         ->  Parallel Index Only Scan using tenk1_unique1 on tenk1
   SubPlan 1
     ->  Result
           One-Time Filter: (tenk1_vw_sec.unique1 = 0)
   SubPlan 2
     ->  Result
(10 rows)

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)

While that's obviously a far better plan, it does not meet this test
case's stated goal of testing the interaction of subqueries with
parallel query.  Could you suggest a less trivial subquery that will
still do what you intended?

			regards, tom lane