subselect_optimizer.out 24.9 KB
Newer Older
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57
--
-- SUBSELECT
--
SELECT 1 AS one WHERE 1 IN (SELECT 1);
 one 
-----
   1
(1 row)

SELECT 1 AS zero WHERE 1 NOT IN (SELECT 1);
 zero 
------
(0 rows)

SELECT 1 AS zero WHERE 1 IN (SELECT 2);
 zero 
------
(0 rows)

-- Check grammar's handling of extra parens in assorted contexts
SELECT * FROM (SELECT 1 AS x) ss;
 x 
---
 1
(1 row)

SELECT * FROM ((SELECT 1 AS x)) ss;
 x 
---
 1
(1 row)

(SELECT 2) UNION SELECT 2;
 ?column? 
----------
        2
(1 row)

((SELECT 2)) UNION SELECT 2;
 ?column? 
----------
        2
(1 row)

SELECT ((SELECT 2) UNION SELECT 2);
 ?column? 
----------
        2
(1 row)

SELECT (((SELECT 2)) UNION SELECT 2);
 ?column? 
----------
        2
(1 row)

SELECT (SELECT ARRAY[1,2,3])[1];
R
Richard Guo 已提交
58 59 60
 array 
-------
     1
61 62 63
(1 row)

SELECT ((SELECT ARRAY[1,2,3]))[2];
R
Richard Guo 已提交
64 65 66
 array 
-------
     2
67 68 69
(1 row)

SELECT (((SELECT ARRAY[1,2,3])))[3];
R
Richard Guo 已提交
70 71 72
 array 
-------
     3
73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88
(1 row)

-- Set up some simple test tables
CREATE TABLE SUBSELECT_TBL (
  f1 integer,
  f2 integer,
  f3 float
);
INSERT INTO SUBSELECT_TBL VALUES (1, 2, 3);
INSERT INTO SUBSELECT_TBL VALUES (2, 3, 4);
INSERT INTO SUBSELECT_TBL VALUES (3, 4, 5);
INSERT INTO SUBSELECT_TBL VALUES (1, 1, 1);
INSERT INTO SUBSELECT_TBL VALUES (2, 2, 2);
INSERT INTO SUBSELECT_TBL VALUES (3, 3, 3);
INSERT INTO SUBSELECT_TBL VALUES (6, 7, 8);
INSERT INTO SUBSELECT_TBL VALUES (8, 9, NULL);
89
SELECT '' AS eight, * FROM SUBSELECT_TBL;
90 91 92 93 94
 eight | f1 | f2 | f3 
-------+----+----+----
       |  1 |  2 |  3
       |  2 |  3 |  4
       |  3 |  4 |  5
95 96 97
       |  1 |  1 |  1
       |  2 |  2 |  2
       |  3 |  3 |  3
98 99 100 101 102 103
       |  6 |  7 |  8
       |  8 |  9 |   
(8 rows)

-- Uncorrelated subselects
SELECT '' AS two, f1 AS "Constant Select" FROM SUBSELECT_TBL
104
  WHERE f1 IN (SELECT 1);
105 106 107 108 109 110 111
 two | Constant Select 
-----+-----------------
     |               1
     |               1
(2 rows)

SELECT '' AS six, f1 AS "Uncorrelated Field" FROM SUBSELECT_TBL
112
  WHERE f1 IN (SELECT f2 FROM SUBSELECT_TBL);
113 114 115 116 117
 six | Uncorrelated Field 
-----+--------------------
     |                  1
     |                  2
     |                  3
118 119
     |                  1
     |                  2
120 121 122 123 124
     |                  3
(6 rows)

SELECT '' AS six, f1 AS "Uncorrelated Field" FROM SUBSELECT_TBL
  WHERE f1 IN (SELECT f2 FROM SUBSELECT_TBL WHERE
125
    f2 IN (SELECT f1 FROM SUBSELECT_TBL));
126 127 128 129 130
 six | Uncorrelated Field 
-----+--------------------
     |                  1
     |                  2
     |                  3
131 132
     |                  1
     |                  2
133 134 135 136 137 138
     |                  3
(6 rows)

SELECT '' AS three, f1, f2
  FROM SUBSELECT_TBL
  WHERE (f1, f2) NOT IN (SELECT f2, CAST(f3 AS int4) FROM SUBSELECT_TBL
139
                         WHERE f3 IS NOT NULL);
140 141 142 143 144 145 146 147 148 149
 three | f1 | f2 
-------+----+----
       |  1 |  2
       |  6 |  7
       |  8 |  9
(3 rows)

-- Correlated subselects
SELECT '' AS six, f1 AS "Correlated Field", f2 AS "Second Field"
  FROM SUBSELECT_TBL upper
150
  WHERE f1 IN (SELECT f2 FROM SUBSELECT_TBL WHERE f1 = upper.f1);
151 152 153 154 155
 six | Correlated Field | Second Field 
-----+------------------+--------------
     |                1 |            2
     |                2 |            3
     |                3 |            4
156 157 158
     |                1 |            1
     |                2 |            2
     |                3 |            3
159 160 161 162 163
(6 rows)

SELECT '' AS six, f1 AS "Correlated Field", f3 AS "Second Field"
  FROM SUBSELECT_TBL upper
  WHERE f1 IN
164
    (SELECT f2 FROM SUBSELECT_TBL WHERE CAST(upper.f2 AS float) = f3);
165 166
 six | Correlated Field | Second Field 
-----+------------------+--------------
167 168
     |                2 |            4
     |                3 |            5
169 170 171 172 173 174 175 176
     |                1 |            1
     |                2 |            2
     |                3 |            3
(5 rows)

SELECT '' AS six, f1 AS "Correlated Field", f3 AS "Second Field"
  FROM SUBSELECT_TBL upper
  WHERE f3 IN (SELECT upper.f1 + f2 FROM SUBSELECT_TBL
177
               WHERE f2 = CAST(f3 AS integer));
178 179 180 181 182 183 184 185 186 187 188
 six | Correlated Field | Second Field 
-----+------------------+--------------
     |                1 |            3
     |                2 |            4
     |                3 |            5
     |                6 |            8
(4 rows)

SELECT '' AS five, f1 AS "Correlated Field"
  FROM SUBSELECT_TBL
  WHERE (f1, f2) IN (SELECT f2, CAST(f3 AS int4) FROM SUBSELECT_TBL
189
                     WHERE f3 IS NOT NULL);
190 191 192 193
 five | Correlated Field 
------+------------------
      |                2
      |                3
194 195
      |                1
      |                2
196 197 198 199 200 201 202 203 204
      |                3
(5 rows)

--
-- Use some existing tables in the regression test
--
SELECT '' AS eight, ss.f1 AS "Correlated Field", ss.f3 AS "Second Field"
  FROM SUBSELECT_TBL ss
  WHERE f1 NOT IN (SELECT f1+1 FROM INT4_TBL
205
                   WHERE f1 != ss.f1 AND f1 < 2147483647);
206 207 208 209
 eight | Correlated Field | Second Field 
-------+------------------+--------------
       |                2 |            4
       |                3 |            5
210 211
       |                2 |            2
       |                3 |            3
212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272
       |                6 |            8
       |                8 |             
(6 rows)

select q1, float8(count(*)) / (select count(*) from int8_tbl)
from int8_tbl group by q1 order by q1;
        q1        | ?column? 
------------------+----------
              123 |      0.4
 4567890123456789 |      0.6
(2 rows)

--
-- Test cases to catch unpleasant interactions between IN-join processing
-- and subquery pullup.
--
select count(*) from
  (select 1 from tenk1 a
   where unique1 IN (select hundred from tenk1 b)) ss;
 count 
-------
   100
(1 row)

select count(distinct ss.ten) from
  (select ten from tenk1 a
   where unique1 IN (select hundred from tenk1 b)) ss;
 count 
-------
    10
(1 row)

select count(*) from
  (select 1 from tenk1 a
   where unique1 IN (select distinct hundred from tenk1 b)) ss;
 count 
-------
   100
(1 row)

select count(distinct ss.ten) from
  (select ten from tenk1 a
   where unique1 IN (select distinct hundred from tenk1 b)) ss;
 count 
-------
    10
(1 row)

--
-- Test cases to check for overenthusiastic optimization of
-- "IN (SELECT DISTINCT ...)" and related cases.  Per example from
-- Luca Pireddu and Michael Fuhr.
--
CREATE TEMP TABLE foo (id integer);
CREATE TEMP TABLE bar (id1 integer, id2 integer);
INSERT INTO foo VALUES (1);
INSERT INTO bar VALUES (1, 1);
INSERT INTO bar VALUES (2, 2);
INSERT INTO bar VALUES (3, 1);
-- These cases require an extra level of distinct-ing above subquery s
SELECT * FROM foo WHERE id IN
273
    (SELECT id2 FROM (SELECT DISTINCT id1, id2 FROM bar) AS s);
274 275 276 277 278 279
 id 
----
  1
(1 row)

SELECT * FROM foo WHERE id IN
280
    (SELECT id2 FROM (SELECT id1,id2 FROM bar GROUP BY id1,id2) AS s);
281 282 283 284 285 286 287
 id 
----
  1
(1 row)

SELECT * FROM foo WHERE id IN
    (SELECT id2 FROM (SELECT id1, id2 FROM bar UNION
288
                      SELECT id1, id2 FROM bar) AS s);
289 290 291 292 293 294 295
 id 
----
  1
(1 row)

-- These cases do not
SELECT * FROM foo WHERE id IN
296
    (SELECT id2 FROM (SELECT DISTINCT ON (id2) id1, id2 FROM bar) AS s);
297 298 299 300 301 302
 id 
----
  1
(1 row)

SELECT * FROM foo WHERE id IN
303
    (SELECT id2 FROM (SELECT id2 FROM bar GROUP BY id2) AS s);
304 305 306 307 308 309 310
 id 
----
  1
(1 row)

SELECT * FROM foo WHERE id IN
    (SELECT id2 FROM (SELECT id2 FROM bar UNION
311
                      SELECT id2 FROM bar) AS s);
312 313 314 315 316 317 318 319 320 321 322 323
 id 
----
  1
(1 row)

--
-- Test case to catch problems with multiply nested sub-SELECTs not getting
-- recalculated properly.  Per bug report from Didier Moens.
--
CREATE TABLE orderstest (
    approver_ref integer,
    po_ref integer,
R
Richard Guo 已提交
324
    ordercanceled boolean
325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342
);
INSERT INTO orderstest VALUES (1, 1, false);
INSERT INTO orderstest VALUES (66, 5, false);
INSERT INTO orderstest VALUES (66, 6, false);
INSERT INTO orderstest VALUES (66, 7, false);
INSERT INTO orderstest VALUES (66, 1, true);
INSERT INTO orderstest VALUES (66, 8, false);
INSERT INTO orderstest VALUES (66, 1, false);
INSERT INTO orderstest VALUES (77, 1, false);
INSERT INTO orderstest VALUES (1, 1, false);
INSERT INTO orderstest VALUES (66, 1, false);
INSERT INTO orderstest VALUES (1, 1, false);
CREATE VIEW orders_view AS
SELECT *,
(SELECT CASE
   WHEN ord.approver_ref=1 THEN '---' ELSE 'Approved'
 END) AS "Approved",
(SELECT CASE
R
Richard Guo 已提交
343 344
 WHEN ord.ordercanceled
 THEN 'Canceled'
345 346 347 348 349 350 351 352 353 354
 ELSE
  (SELECT CASE
		WHEN ord.po_ref=1
		THEN
		 (SELECT CASE
				WHEN ord.approver_ref=1
				THEN '---'
				ELSE 'Approved'
			END)
		ELSE 'PO'
A
Asim R P 已提交
355
	END)
356 357
END) AS "Status",
(CASE
R
Richard Guo 已提交
358 359
 WHEN ord.ordercanceled
 THEN 'Canceled'
360 361 362 363 364 365 366 367 368 369
 ELSE
  (CASE
		WHEN ord.po_ref=1
		THEN
		 (CASE
				WHEN ord.approver_ref=1
				THEN '---'
				ELSE 'Approved'
			END)
		ELSE 'PO'
A
Asim R P 已提交
370
	END)
371 372
END) AS "Status_OK"
FROM orderstest ord;
373
SELECT * FROM orders_view;
R
Richard Guo 已提交
374 375 376 377 378 379 380 381 382 383 384 385 386
 approver_ref | po_ref | ordercanceled | Approved |  Status  | Status_OK 
--------------+--------+---------------+----------+----------+-----------
            1 |      1 | f             | ---      | ---      | ---
           66 |      5 | f             | Approved | PO       | PO
           66 |      6 | f             | Approved | PO       | PO
           66 |      7 | f             | Approved | PO       | PO
           66 |      1 | t             | Approved | Canceled | Canceled
           66 |      8 | f             | Approved | PO       | PO
           66 |      1 | f             | Approved | Approved | Approved
           77 |      1 | f             | Approved | Approved | Approved
            1 |      1 | f             | ---      | ---      | ---
           66 |      1 | f             | Approved | Approved | Approved
            1 |      1 | f             | ---      | ---      | ---
387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420
(11 rows)

DROP TABLE orderstest cascade;
NOTICE:  drop cascades to view orders_view
--
-- Test cases to catch situations where rule rewriter fails to propagate
-- hasSubLinks flag correctly.  Per example from Kyle Bateman.
--
create temp table parts (
    partnum     text,
    cost        float8
);
create temp table shipped (
    ttype       char(2),
    ordnum      int4,
    partnum     text,
    value       float8
);
create temp view shipped_view as
    select * from shipped where ttype = 'wt';
create rule shipped_view_insert as on insert to shipped_view do instead
    insert into shipped values('wt', new.ordnum, new.partnum, new.value);
insert into parts (partnum, cost) values (1, 1234.56);
insert into shipped_view (ordnum, partnum, value)
    values (0, 1, (select cost from parts where partnum = '1'));
select * from shipped_view;
 ttype | ordnum | partnum |  value  
-------+--------+---------+---------
 wt    |      0 | 1       | 1234.56
(1 row)

create rule shipped_view_update as on update to shipped_view do instead
    update shipped set partnum = new.partnum, value = new.value
        where ttype = new.ttype and ordnum = new.ordnum;
421 422 423 424
update shipped_view set value = 11
    from int4_tbl a join int4_tbl b
      on (a.f1 = (select f1 from int4_tbl c where c.f1=b.f1))
    where ordnum = a.f1;
425
select * from shipped_view;
426 427 428
 ttype | ordnum | partnum | value 
-------+--------+---------+-------
 wt    |      0 | 1       |    11
429 430 431 432 433 434 435 436 437 438
(1 row)

select f1, ss1 as relabel from
    (select *, (select sum(f1) from int4_tbl b where f1 >= a.f1) as ss1
     from int4_tbl a) ss;
     f1      |  relabel   
-------------+------------
           0 | 2147607103
      123456 | 2147607103
     -123456 | 2147483647
439
  2147483647 | 2147483647
440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537
 -2147483647 |          0
(5 rows)

--
-- Test cases involving PARAM_EXEC parameters and min/max index optimizations.
-- Per bug report from David Sanchez i Gregori.
--
select * from (
  select max(unique1) from tenk1 as a
  where exists (select 1 from tenk1 as b where b.thousand = a.unique2)
) ss;
 max  
------
 9997
(1 row)

select * from (
  select min(unique1) from tenk1 as a
  where not exists (select 1 from tenk1 as b where b.unique2 = 10000)
) ss;
 min 
-----
   0
(1 row)

--
-- Test that an IN implemented using a UniquePath does unique-ification
-- with the right semantics, as per bug #4113.  (Unfortunately we have
-- no simple way to ensure that this test case actually chooses that type
-- of plan, but it does in releases 7.4-8.3.  Note that an ordering difference
-- here might mean that some other plan type is being used, rendering the test
-- pointless.)
--
create temp table numeric_table (num_col numeric);
NOTICE:  Table doesn't have 'DISTRIBUTED BY' clause -- Using column named 'num_col' as the Greenplum Database data distribution key for this table.
HINT:  The 'DISTRIBUTED BY' clause determines the distribution of data. Make sure column(s) chosen are the optimal data distribution key to minimize skew.
insert into numeric_table values (1), (1.000000000000000000001), (2), (3);
create temp table float_table (float_col float8);
NOTICE:  Table doesn't have 'DISTRIBUTED BY' clause -- Using column named 'float_col' as the Greenplum Database data distribution key for this table.
HINT:  The 'DISTRIBUTED BY' clause determines the distribution of data. Make sure column(s) chosen are the optimal data distribution key to minimize skew.
insert into float_table values (1), (2), (3);
select * from float_table
  where float_col in (select num_col from numeric_table);
 float_col 
-----------
         1
         2
         3
(3 rows)

select * from numeric_table
  where num_col in (select float_col from float_table);
         num_col         
-------------------------
                       1
                       2
 1.000000000000000000001
                       3
(4 rows)

--
-- Test case for bug #4290: bogus calculation of subplan param sets
--
create temp table ta (id int primary key, val int);
insert into ta values(1,1);
insert into ta values(2,2);
create temp table tb (id int primary key, aval int);
insert into tb values(1,1);
insert into tb values(2,1);
insert into tb values(3,2);
insert into tb values(4,2);
create temp table tc (id int primary key, aid int);
insert into tc values(1,1);
insert into tc values(2,2);
select
  ( select min(tb.id) from tb
    where tb.aval = (select ta.val from ta where ta.id = tc.aid) ) as min_tb_id
from tc;
 min_tb_id 
-----------
         1
         3
(2 rows)

--
-- Test case for 8.3 "failed to locate grouping columns" bug
--
create temp table t1 (f1 numeric(14,0), f2 varchar(30));
NOTICE:  Table doesn't have 'DISTRIBUTED BY' clause -- Using column named 'f1' as the Greenplum Database data distribution key for this table.
HINT:  The 'DISTRIBUTED BY' clause determines the distribution of data. Make sure column(s) chosen are the optimal data distribution key to minimize skew.
select * from
  (select distinct f1, f2, (select f2 from t1 x where x.f1 = up.f1) as fs
   from t1 up) ss
group by f1,f2,fs;
 f1 | f2 | fs 
----+----+----
(0 rows)

538 539 540 541 542 543 544 545 546 547 548 549 550
--
-- Test case for bug #5514 (mishandling of whole-row Vars in subselects)
--
create temp table table_a(id integer);
insert into table_a values (42);
create temp view view_a as select * from table_a;
select view_a from view_a;
 view_a 
--------
 (42)
(1 row)

select (select view_a) from view_a;
R
Richard Guo 已提交
551 552
 view_a 
--------
553 554 555 556
 (42)
(1 row)

select (select (select view_a)) from view_a;
R
Richard Guo 已提交
557 558
 view_a 
--------
559 560 561 562
 (42)
(1 row)

select (select (a.*)::text) from view_a a;
R
Richard Guo 已提交
563 564
  a   
------
565 566 567
 (42)
(1 row)

568 569 570 571
--
-- Check that whole-row Vars reading the result of a subselect don't include
-- any junk columns therein
--
572 573 574 575
-- In GPDB, the ORDER BY in the subquery or CTE doesn't force an ordering
-- for the whole query. Mark these with the "order none" gpdiff directive,
-- so that differences in result order are ignored.
select q from (select max(f1) from int4_tbl group by f1 order by f1) q;  -- order none
576
       q       
577 578 579 580 581 582 583 584 585
---------------
 (-2147483647)
 (-123456)
 (0)
 (123456)
 (2147483647)
(5 rows)

with q as (select max(f1) from int4_tbl group by f1 order by f1)
586
  select q from q;  -- order none
587 588 589 590 591 592 593 594 595
       q       
---------------
 (-2147483647)
 (-123456)
 (0)
 (123456)
 (2147483647)
(5 rows)

596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613
--
-- Test case for sublinks pushed down into subselects via join alias expansion
--
-- Greenplum note: This query will only work with ORCA. This type of query
-- was not supported in postgres versions prior to 8.4, and thus was never
-- supported in the planner. After 8.4 versions, the planner works, but
-- the plan it creates is not currently parallel safe.
select
  (select sq1) as qq1
from
  (select exists(select 1 from int4_tbl where f1 = q2) as sq1, 42 as dummy
   from int8_tbl) sq0
  join
  int4_tbl i4 on dummy = i4.f1;
 qq1 
-----
(0 rows)

614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643
--
-- Test case for cross-type partial matching in hashed subplan (bug #7597)
--
create temp table outer_7597 (f1 int4, f2 int4);
NOTICE:  Table doesn't have 'DISTRIBUTED BY' clause -- Using column named 'f1' as the Greenplum Database data distribution key for this table.
HINT:  The 'DISTRIBUTED BY' clause determines the distribution of data. Make sure column(s) chosen are the optimal data distribution key to minimize skew.
insert into outer_7597 values (0, 0);
insert into outer_7597 values (1, 0);
insert into outer_7597 values (0, null);
insert into outer_7597 values (1, null);
create temp table inner_7597(c1 int8, c2 int8);
NOTICE:  Table doesn't have 'DISTRIBUTED BY' clause -- Using column named 'c1' as the Greenplum Database data distribution key for this table.
HINT:  The 'DISTRIBUTED BY' clause determines the distribution of data. Make sure column(s) chosen are the optimal data distribution key to minimize skew.
insert into inner_7597 values(0, null);
select * from outer_7597 where (f1, f2) not in (select * from inner_7597);
 f1 | f2 
----+----
  1 |  0
  1 |   
(2 rows)

--
-- Test case for premature memory release during hashing of subplan output
--
select '1'::text in (select '1'::name union all select '1'::name);
 ?column? 
----------
 t
(1 row)

R
Richard Guo 已提交
644 645 646 647
--
-- Test case for planner bug with nested EXISTS handling
--
-- GPDB_92_MERGE_FIXME: ORCA cannot decorrelate this query, and generates
648 649 650 651
-- correct-but-slow plan that takes 45 minutes. Revisit this when ORCA can
-- reorder anti-joins
set optimizer to off;
select a.thousand from tenk1 a, tenk1 b
R
Richard Guo 已提交
652 653 654 655 656 657 658 659
where a.thousand = b.thousand
  and exists ( select 1 from tenk1 c where b.hundred = c.hundred
                   and not exists ( select 1 from tenk1 d
                                    where a.thousand = d.thousand ) );
 thousand 
----------
(0 rows)

660
reset optimizer;
661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681
--
-- Check that nested sub-selects are not pulled up if they contain volatiles
--
explain (verbose, costs off)
  select x, x from
    (select (select current_database()) as x from (values(1),(2)) v(y)) ss;
                   QUERY PLAN                   
------------------------------------------------
 Result
   Output: current_database, current_database
   ->  Result
         Output: current_database
         ->  Nested Loop Left Join
               Output: current_database
               Join Filter: true
               ->  Values Scan on "Values"
                     Output: column1
               ->  Result
                     Output: 'regression'::name
                     ->  Result
                           Output: true
682
 Optimizer: Pivotal Optimizer (GPORCA) version 3.1.0
683 684 685 686 687 688 689 690 691 692 693 694 695 696 697
 Settings: optimizer=on
(15 rows)

explain (verbose, costs off)
  select x, x from
    (select (select random()) as x from (values(1),(2)) v(y)) ss;
            QUERY PLAN             
-----------------------------------
 Subquery Scan on ss
   Output: ss.x, ss.x
   ->  Values Scan on "*VALUES*"
         Output: $0
         InitPlan 1 (returns $0)
           ->  Result
                 Output: random()
698
 Optimizer: Postgres query optimizer
699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718
(8 rows)

explain (verbose, costs off)
  select x, x from
    (select (select current_database() where y=y) as x from (values(1),(2)) v(y)) ss;
                            QUERY PLAN                            
------------------------------------------------------------------
 Result
   Output: current_database, current_database
   ->  Result
         Output: current_database
         ->  Nested Loop Left Join
               Output: current_database
               Join Filter: ("Values".column1 = "Values".column1)
               ->  Values Scan on "Values"
                     Output: column1
               ->  Result
                     Output: 'regression'::name
                     ->  Result
                           Output: true
719
 Optimizer: Pivotal Optimizer (GPORCA) version 3.1.0
720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735
 Settings: optimizer=on
(15 rows)

explain (verbose, costs off)
  select x, x from
    (select (select random() where y=y) as x from (values(1),(2)) v(y)) ss;
                                 QUERY PLAN                                 
----------------------------------------------------------------------------
 Subquery Scan on ss
   Output: ss.x, ss.x
   ->  Values Scan on "*VALUES*"
         Output: (SubPlan 1)
         SubPlan 1
           ->  Result
                 Output: random()
                 One-Time Filter: ("*VALUES*".column1 = "*VALUES*".column1)
736
 Optimizer: Postgres query optimizer
737 738 739 740 741 742 743 744 745 746 747 748 749
(9 rows)

--
-- Check we behave sanely in corner case of empty SELECT list (bug #8648)
--
create temp table nocolumns();
NOTICE:  Table doesn't have 'DISTRIBUTED BY' clause, and no column type is suitable for a distribution key. Creating a NULL policy entry.
select exists(select * from nocolumns);
 exists 
--------
 f
(1 row)

750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779
--
-- Check behavior with a SubPlan in VALUES (bug #14924)
--
select val.x
  from generate_series(1,10) as s(i),
  lateral (
    values ((select s.i + 1)), (s.i + 101)
  ) as val(x)
where s.i < 10 and (select val.x) < 110;
  x  
-----
   2
 102
   3
 103
   4
 104
   5
 105
   6
 106
   7
 107
   8
 108
   9
 109
  10
(17 rows)

780 781 782 783 784 785 786 787 788 789 790 791 792 793 794
--
-- Check sane behavior with nested IN SubLinks
-- GPDB_94_MERGE_FIXME: ORCA plan is correct but very pricy. Should we fallback to planner?
--
explain (verbose, costs off)
select * from int4_tbl where
  (case when f1 in (select unique1 from tenk1 a) then f1 else null end) in
  (select ten from tenk1 b);
                             QUERY PLAN                             
--------------------------------------------------------------------
 Result
   Output: int4_tbl.f1
   Filter: (SubPlan 2)
   ->  Gather Motion 3:1  (slice1; segments: 3)
         Output: int4_tbl.f1
795
         ->  Seq Scan on public.int4_tbl
796 797 798 799 800 801 802 803 804 805
               Output: int4_tbl.f1
   SubPlan 1  (slice0)
     ->  Result
           Output: tenk1.unique1
           ->  Result
                 Output: true, tenk1.unique1
                 ->  Materialize
                       Output: tenk1.unique1
                       ->  Gather Motion 3:1  (slice2; segments: 3)
                             Output: tenk1.unique1
806
                             ->  Seq Scan on public.tenk1
807 808 809 810 811 812
                                   Output: tenk1.unique1
   SubPlan 2  (slice0)
     ->  Materialize
           Output: tenk1_1.ten
           ->  Gather Motion 3:1  (slice3; segments: 3)
                 Output: tenk1_1.ten
813
                 ->  Seq Scan on public.tenk1 tenk1_1
814
                       Output: tenk1_1.ten
815
 Optimizer: Pivotal Optimizer (GPORCA) version 3.1.0
816 817 818 819 820 821 822 823 824 825 826
 Settings: optimizer=on
(27 rows)

select * from int4_tbl where
  (case when f1 in (select unique1 from tenk1 a) then f1 else null end) in
  (select ten from tenk1 b);
 f1 
----
  0
(1 row)

827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850
--
-- Check for incorrect optimization when IN subquery contains a SRF
--
explain (verbose, costs off)
select * from int4_tbl o where (f1, f1) in
  (select f1, generate_series(1,2) / 10 g from int4_tbl i group by f1);
                              QUERY PLAN                              
----------------------------------------------------------------------
 Gather Motion 3:1  (slice1; segments: 3)
   Output: o.f1
   ->  Hash Semi Join
         Output: o.f1
         Hash Cond: (o.f1 = "ANY_subquery".f1)
         ->  Seq Scan on public.int4_tbl o
               Output: o.f1
         ->  Hash
               Output: "ANY_subquery".f1, "ANY_subquery".g
               ->  Subquery Scan on "ANY_subquery"
                     Output: "ANY_subquery".f1, "ANY_subquery".g
                     Filter: ("ANY_subquery".f1 = "ANY_subquery".g)
                     ->  Result
                           Output: i.f1, (generate_series(1, 2) / 10)
                           ->  Seq Scan on public.int4_tbl i
                                 Output: i.f1
851
 Optimizer: Postgres query optimizer
852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904
(17 rows)

select * from int4_tbl o where (f1, f1) in
  (select f1, generate_series(1,2) / 10 g from int4_tbl i group by f1);
 f1 
----
  0
(1 row)

--
-- check for over-optimization of whole-row Var referencing an Append plan
--
select (select q from
         (select 1,2,3 where f1 > 0
          union all
          select 4,5,6.0 where f1 <= 0
         ) q )
from int4_tbl;
     q     
-----------
 (4,5,6.0)
 (4,5,6.0)
 (1,2,3)
 (1,2,3)
 (4,5,6.0)
(5 rows)

--
-- Check that volatile quals aren't pushed down past a DISTINCT:
-- nextval() should not be called more than the nominal number of times
--
create temp sequence ts1;
select * from
  (select distinct ten from tenk1) ss
  where ten < 10 + nextval('ts1')
  order by 1;
 ten 
-----
   0
   1
   2
   3
   4
   5
   6
   7
   8
   9
(10 rows)

select nextval('ts1');
 nextval 
---------
905
      11
906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921
(1 row)

--
-- Ensure that backward scan direction isn't propagated into
-- expression subqueries (bug #15336)
--
--start_ignore
begin;
declare c1 scroll cursor for
 select * from generate_series(1,4) i
  where i <> all (values (2),(3));
move forward all in c1;
fetch backward all in c1;
ERROR:  backward scan is not supported in this version of Greenplum Database
commit;
--end_ignore