Soon-to-be-broken regression test case

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