1999-02-23 08:27:13 +01:00
|
|
|
--
|
2000-01-06 07:41:55 +01:00
|
|
|
-- JOIN
|
2000-09-12 23:07:18 +02:00
|
|
|
-- Test JOIN clauses
|
1999-02-23 08:27:13 +01:00
|
|
|
--
|
|
|
|
|
2000-02-15 04:31:33 +01:00
|
|
|
CREATE TABLE J1_TBL (
|
1999-02-23 08:27:13 +01:00
|
|
|
i integer,
|
|
|
|
j integer,
|
2000-01-05 07:07:58 +01:00
|
|
|
t text
|
1999-02-23 08:27:13 +01:00
|
|
|
);
|
|
|
|
|
2000-02-15 04:31:33 +01:00
|
|
|
CREATE TABLE J2_TBL (
|
1999-02-23 08:27:13 +01:00
|
|
|
i integer,
|
|
|
|
k integer
|
|
|
|
);
|
|
|
|
|
2000-01-05 07:07:58 +01:00
|
|
|
|
2000-11-06 17:03:47 +01:00
|
|
|
INSERT INTO J1_TBL VALUES (1, 4, 'one');
|
|
|
|
INSERT INTO J1_TBL VALUES (2, 3, 'two');
|
|
|
|
INSERT INTO J1_TBL VALUES (3, 2, 'three');
|
|
|
|
INSERT INTO J1_TBL VALUES (4, 1, 'four');
|
|
|
|
INSERT INTO J1_TBL VALUES (5, 0, 'five');
|
|
|
|
INSERT INTO J1_TBL VALUES (6, 6, 'six');
|
|
|
|
INSERT INTO J1_TBL VALUES (7, 7, 'seven');
|
|
|
|
INSERT INTO J1_TBL VALUES (8, 8, 'eight');
|
|
|
|
INSERT INTO J1_TBL VALUES (0, NULL, 'zero');
|
|
|
|
INSERT INTO J1_TBL VALUES (NULL, NULL, 'null');
|
|
|
|
INSERT INTO J1_TBL VALUES (NULL, 0, 'zero');
|
1999-02-23 08:27:13 +01:00
|
|
|
|
2000-02-15 04:31:33 +01:00
|
|
|
INSERT INTO J2_TBL VALUES (1, -1);
|
|
|
|
INSERT INTO J2_TBL VALUES (2, 2);
|
|
|
|
INSERT INTO J2_TBL VALUES (3, -3);
|
|
|
|
INSERT INTO J2_TBL VALUES (2, 4);
|
2000-09-12 23:07:18 +02:00
|
|
|
INSERT INTO J2_TBL VALUES (5, -5);
|
2000-11-06 17:03:47 +01:00
|
|
|
INSERT INTO J2_TBL VALUES (5, -5);
|
|
|
|
INSERT INTO J2_TBL VALUES (0, NULL);
|
|
|
|
INSERT INTO J2_TBL VALUES (NULL, NULL);
|
|
|
|
INSERT INTO J2_TBL VALUES (NULL, 0);
|
2000-02-15 04:31:33 +01:00
|
|
|
|
|
|
|
--
|
|
|
|
-- CORRELATION NAMES
|
|
|
|
-- Make sure that table/column aliases are supported
|
|
|
|
-- before diving into more complex join syntax.
|
|
|
|
--
|
|
|
|
|
|
|
|
SELECT '' AS "xxx", *
|
|
|
|
FROM J1_TBL AS tx;
|
|
|
|
|
|
|
|
SELECT '' AS "xxx", *
|
|
|
|
FROM J1_TBL tx;
|
|
|
|
|
|
|
|
SELECT '' AS "xxx", *
|
|
|
|
FROM J1_TBL AS t1 (a, b, c);
|
|
|
|
|
|
|
|
SELECT '' AS "xxx", *
|
|
|
|
FROM J1_TBL t1 (a, b, c);
|
|
|
|
|
|
|
|
SELECT '' AS "xxx", *
|
|
|
|
FROM J1_TBL t1 (a, b, c), J2_TBL t2 (d, e);
|
|
|
|
|
|
|
|
SELECT '' AS "xxx", t1.a, t2.e
|
|
|
|
FROM J1_TBL t1 (a, b, c), J2_TBL t2 (d, e)
|
|
|
|
WHERE t1.a = t2.d;
|
1999-02-23 08:27:13 +01:00
|
|
|
|
|
|
|
|
2000-01-05 07:07:58 +01:00
|
|
|
--
|
|
|
|
-- CROSS JOIN
|
|
|
|
-- Qualifications are not allowed on cross joins,
|
|
|
|
-- which degenerate into a standard unqualified inner join.
|
|
|
|
--
|
|
|
|
|
|
|
|
SELECT '' AS "xxx", *
|
2000-02-15 04:31:33 +01:00
|
|
|
FROM J1_TBL CROSS JOIN J2_TBL;
|
2000-01-05 07:07:58 +01:00
|
|
|
|
2000-02-15 04:31:33 +01:00
|
|
|
-- ambiguous column
|
2000-01-05 07:07:58 +01:00
|
|
|
SELECT '' AS "xxx", i, k, t
|
2000-02-15 04:31:33 +01:00
|
|
|
FROM J1_TBL CROSS JOIN J2_TBL;
|
|
|
|
|
|
|
|
-- resolve previous ambiguity by specifying the table name
|
|
|
|
SELECT '' AS "xxx", t1.i, k, t
|
|
|
|
FROM J1_TBL t1 CROSS JOIN J2_TBL t2;
|
2000-01-05 07:07:58 +01:00
|
|
|
|
|
|
|
SELECT '' AS "xxx", ii, tt, kk
|
2000-02-15 04:31:33 +01:00
|
|
|
FROM (J1_TBL CROSS JOIN J2_TBL)
|
|
|
|
AS tx (ii, jj, tt, ii2, kk);
|
2000-01-05 07:07:58 +01:00
|
|
|
|
2000-02-15 04:31:33 +01:00
|
|
|
SELECT '' AS "xxx", tx.ii, tx.jj, tx.kk
|
|
|
|
FROM (J1_TBL t1 (a, b, c) CROSS JOIN J2_TBL t2 (d, e))
|
|
|
|
AS tx (ii, jj, tt, ii2, kk);
|
2000-01-05 07:07:58 +01:00
|
|
|
|
2000-09-12 23:07:18 +02:00
|
|
|
SELECT '' AS "xxx", *
|
|
|
|
FROM J1_TBL CROSS JOIN J2_TBL a CROSS JOIN J2_TBL b;
|
|
|
|
|
2000-01-05 07:07:58 +01:00
|
|
|
|
|
|
|
--
|
1999-02-23 08:27:13 +01:00
|
|
|
--
|
|
|
|
-- Inner joins (equi-joins)
|
|
|
|
--
|
2000-01-05 07:07:58 +01:00
|
|
|
--
|
|
|
|
|
|
|
|
--
|
|
|
|
-- Inner joins (equi-joins) with USING clause
|
|
|
|
-- The USING syntax changes the shape of the resulting table
|
|
|
|
-- by including a column in the USING clause only once in the result.
|
|
|
|
--
|
1999-02-23 08:27:13 +01:00
|
|
|
|
2000-02-15 04:31:33 +01:00
|
|
|
-- Inner equi-join on specified column
|
|
|
|
SELECT '' AS "xxx", *
|
|
|
|
FROM J1_TBL INNER JOIN J2_TBL USING (i);
|
|
|
|
|
|
|
|
-- Same as above, slightly different syntax
|
|
|
|
SELECT '' AS "xxx", *
|
|
|
|
FROM J1_TBL JOIN J2_TBL USING (i);
|
|
|
|
|
|
|
|
SELECT '' AS "xxx", *
|
2000-11-06 19:11:46 +01:00
|
|
|
FROM J1_TBL t1 (a, b, c) JOIN J2_TBL t2 (a, d) USING (a)
|
|
|
|
ORDER BY a, d;
|
2000-02-15 04:31:33 +01:00
|
|
|
|
|
|
|
SELECT '' AS "xxx", *
|
2000-11-06 19:11:46 +01:00
|
|
|
FROM J1_TBL t1 (a, b, c) JOIN J2_TBL t2 (a, b) USING (b)
|
|
|
|
ORDER BY b, t1.a;
|
2000-02-15 04:31:33 +01:00
|
|
|
|
|
|
|
|
|
|
|
--
|
|
|
|
-- NATURAL JOIN
|
2000-01-05 07:07:58 +01:00
|
|
|
-- Inner equi-join on all columns with the same name
|
2000-02-15 04:31:33 +01:00
|
|
|
--
|
|
|
|
|
1999-02-23 08:27:13 +01:00
|
|
|
SELECT '' AS "xxx", *
|
2000-02-15 04:31:33 +01:00
|
|
|
FROM J1_TBL NATURAL JOIN J2_TBL;
|
1999-02-23 08:27:13 +01:00
|
|
|
|
|
|
|
SELECT '' AS "xxx", *
|
2000-02-15 04:31:33 +01:00
|
|
|
FROM J1_TBL t1 (a, b, c) NATURAL JOIN J2_TBL t2 (a, d);
|
1999-02-23 08:27:13 +01:00
|
|
|
|
|
|
|
SELECT '' AS "xxx", *
|
2000-02-15 04:31:33 +01:00
|
|
|
FROM J1_TBL t1 (a, b, c) NATURAL JOIN J2_TBL t2 (d, a);
|
|
|
|
|
|
|
|
-- mismatch number of columns
|
|
|
|
-- currently, Postgres will fill in with underlying names
|
|
|
|
SELECT '' AS "xxx", *
|
|
|
|
FROM J1_TBL t1 (a, b) NATURAL JOIN J2_TBL t2 (a);
|
2000-01-05 07:07:58 +01:00
|
|
|
|
|
|
|
|
|
|
|
--
|
|
|
|
-- Inner joins (equi-joins)
|
|
|
|
--
|
1999-02-23 08:27:13 +01:00
|
|
|
|
|
|
|
SELECT '' AS "xxx", *
|
2000-02-15 04:31:33 +01:00
|
|
|
FROM J1_TBL JOIN J2_TBL ON (J1_TBL.i = J2_TBL.i);
|
1999-02-23 08:27:13 +01:00
|
|
|
|
|
|
|
SELECT '' AS "xxx", *
|
2000-02-15 04:31:33 +01:00
|
|
|
FROM J1_TBL JOIN J2_TBL ON (J1_TBL.i = J2_TBL.k);
|
1999-02-23 08:27:13 +01:00
|
|
|
|
|
|
|
|
|
|
|
--
|
|
|
|
-- Non-equi-joins
|
|
|
|
--
|
|
|
|
|
|
|
|
SELECT '' AS "xxx", *
|
2000-02-15 04:31:33 +01:00
|
|
|
FROM J1_TBL JOIN J2_TBL ON (J1_TBL.i <= J2_TBL.k);
|
1999-02-23 08:27:13 +01:00
|
|
|
|
|
|
|
|
|
|
|
--
|
|
|
|
-- Outer joins
|
2000-11-06 17:03:47 +01:00
|
|
|
-- Note that OUTER is a noise word
|
1999-02-23 08:27:13 +01:00
|
|
|
--
|
|
|
|
|
|
|
|
SELECT '' AS "xxx", *
|
2002-10-28 23:54:45 +01:00
|
|
|
FROM J1_TBL LEFT OUTER JOIN J2_TBL USING (i)
|
2004-12-03 23:19:28 +01:00
|
|
|
ORDER BY i, k, t;
|
1999-02-23 08:27:13 +01:00
|
|
|
|
2000-11-06 17:03:47 +01:00
|
|
|
SELECT '' AS "xxx", *
|
2002-10-28 23:54:45 +01:00
|
|
|
FROM J1_TBL LEFT JOIN J2_TBL USING (i)
|
2004-12-03 23:19:28 +01:00
|
|
|
ORDER BY i, k, t;
|
2000-11-06 17:03:47 +01:00
|
|
|
|
1999-02-23 08:27:13 +01:00
|
|
|
SELECT '' AS "xxx", *
|
2000-02-15 04:31:33 +01:00
|
|
|
FROM J1_TBL RIGHT OUTER JOIN J2_TBL USING (i);
|
1999-02-23 08:27:13 +01:00
|
|
|
|
2000-11-06 17:03:47 +01:00
|
|
|
SELECT '' AS "xxx", *
|
|
|
|
FROM J1_TBL RIGHT JOIN J2_TBL USING (i);
|
|
|
|
|
|
|
|
SELECT '' AS "xxx", *
|
2002-10-28 23:54:45 +01:00
|
|
|
FROM J1_TBL FULL OUTER JOIN J2_TBL USING (i)
|
2004-12-03 23:19:28 +01:00
|
|
|
ORDER BY i, k, t;
|
2000-11-06 17:03:47 +01:00
|
|
|
|
1999-02-23 08:27:13 +01:00
|
|
|
SELECT '' AS "xxx", *
|
2002-10-28 23:54:45 +01:00
|
|
|
FROM J1_TBL FULL JOIN J2_TBL USING (i)
|
2004-12-03 23:19:28 +01:00
|
|
|
ORDER BY i, k, t;
|
1999-02-23 08:27:13 +01:00
|
|
|
|
2000-11-06 17:03:47 +01:00
|
|
|
SELECT '' AS "xxx", *
|
|
|
|
FROM J1_TBL LEFT JOIN J2_TBL USING (i) WHERE (k = 1);
|
|
|
|
|
|
|
|
SELECT '' AS "xxx", *
|
|
|
|
FROM J1_TBL LEFT JOIN J2_TBL USING (i) WHERE (i = 1);
|
|
|
|
|
1999-02-23 08:27:13 +01:00
|
|
|
|
|
|
|
--
|
|
|
|
-- More complicated constructs
|
|
|
|
--
|
|
|
|
|
2002-03-12 01:52:10 +01:00
|
|
|
--
|
|
|
|
-- Multiway full join
|
|
|
|
--
|
|
|
|
|
|
|
|
CREATE TABLE t1 (name TEXT, n INTEGER);
|
|
|
|
CREATE TABLE t2 (name TEXT, n INTEGER);
|
|
|
|
CREATE TABLE t3 (name TEXT, n INTEGER);
|
|
|
|
|
2009-01-19 14:38:47 +01:00
|
|
|
INSERT INTO t1 VALUES ( 'bb', 11 );
|
|
|
|
INSERT INTO t2 VALUES ( 'bb', 12 );
|
|
|
|
INSERT INTO t2 VALUES ( 'cc', 22 );
|
|
|
|
INSERT INTO t2 VALUES ( 'ee', 42 );
|
|
|
|
INSERT INTO t3 VALUES ( 'bb', 13 );
|
|
|
|
INSERT INTO t3 VALUES ( 'cc', 23 );
|
|
|
|
INSERT INTO t3 VALUES ( 'dd', 33 );
|
2002-03-12 01:52:10 +01:00
|
|
|
|
|
|
|
SELECT * FROM t1 FULL JOIN t2 USING (name) FULL JOIN t3 USING (name);
|
|
|
|
|
2002-04-28 21:54:29 +02:00
|
|
|
--
|
|
|
|
-- Test interactions of join syntax and subqueries
|
|
|
|
--
|
|
|
|
|
|
|
|
-- Basic cases (we expect planner to pull up the subquery here)
|
|
|
|
SELECT * FROM
|
|
|
|
(SELECT * FROM t2) as s2
|
|
|
|
INNER JOIN
|
|
|
|
(SELECT * FROM t3) s3
|
|
|
|
USING (name);
|
|
|
|
|
|
|
|
SELECT * FROM
|
|
|
|
(SELECT * FROM t2) as s2
|
|
|
|
LEFT JOIN
|
|
|
|
(SELECT * FROM t3) s3
|
|
|
|
USING (name);
|
|
|
|
|
|
|
|
SELECT * FROM
|
|
|
|
(SELECT * FROM t2) as s2
|
|
|
|
FULL JOIN
|
|
|
|
(SELECT * FROM t3) s3
|
|
|
|
USING (name);
|
|
|
|
|
|
|
|
-- Cases with non-nullable expressions in subquery results;
|
|
|
|
-- make sure these go to null as expected
|
|
|
|
SELECT * FROM
|
|
|
|
(SELECT name, n as s2_n, 2 as s2_2 FROM t2) as s2
|
|
|
|
NATURAL INNER JOIN
|
|
|
|
(SELECT name, n as s3_n, 3 as s3_2 FROM t3) s3;
|
|
|
|
|
|
|
|
SELECT * FROM
|
|
|
|
(SELECT name, n as s2_n, 2 as s2_2 FROM t2) as s2
|
|
|
|
NATURAL LEFT JOIN
|
|
|
|
(SELECT name, n as s3_n, 3 as s3_2 FROM t3) s3;
|
|
|
|
|
|
|
|
SELECT * FROM
|
|
|
|
(SELECT name, n as s2_n, 2 as s2_2 FROM t2) as s2
|
|
|
|
NATURAL FULL JOIN
|
|
|
|
(SELECT name, n as s3_n, 3 as s3_2 FROM t3) s3;
|
|
|
|
|
|
|
|
SELECT * FROM
|
|
|
|
(SELECT name, n as s1_n, 1 as s1_1 FROM t1) as s1
|
|
|
|
NATURAL INNER JOIN
|
|
|
|
(SELECT name, n as s2_n, 2 as s2_2 FROM t2) as s2
|
|
|
|
NATURAL INNER JOIN
|
|
|
|
(SELECT name, n as s3_n, 3 as s3_2 FROM t3) s3;
|
|
|
|
|
|
|
|
SELECT * FROM
|
|
|
|
(SELECT name, n as s1_n, 1 as s1_1 FROM t1) as s1
|
|
|
|
NATURAL FULL JOIN
|
|
|
|
(SELECT name, n as s2_n, 2 as s2_2 FROM t2) as s2
|
|
|
|
NATURAL FULL JOIN
|
|
|
|
(SELECT name, n as s3_n, 3 as s3_2 FROM t3) s3;
|
|
|
|
|
|
|
|
SELECT * FROM
|
|
|
|
(SELECT name, n as s1_n FROM t1) as s1
|
|
|
|
NATURAL FULL JOIN
|
|
|
|
(SELECT * FROM
|
|
|
|
(SELECT name, n as s2_n FROM t2) as s2
|
|
|
|
NATURAL FULL JOIN
|
|
|
|
(SELECT name, n as s3_n FROM t3) as s3
|
|
|
|
) ss2;
|
|
|
|
|
|
|
|
SELECT * FROM
|
|
|
|
(SELECT name, n as s1_n FROM t1) as s1
|
|
|
|
NATURAL FULL JOIN
|
|
|
|
(SELECT * FROM
|
|
|
|
(SELECT name, n as s2_n, 2 as s2_2 FROM t2) as s2
|
|
|
|
NATURAL FULL JOIN
|
|
|
|
(SELECT name, n as s3_n FROM t3) as s3
|
|
|
|
) ss2;
|
|
|
|
|
2003-02-10 18:08:50 +01:00
|
|
|
|
|
|
|
-- Test for propagation of nullability constraints into sub-joins
|
|
|
|
|
|
|
|
create temp table x (x1 int, x2 int);
|
|
|
|
insert into x values (1,11);
|
|
|
|
insert into x values (2,22);
|
|
|
|
insert into x values (3,null);
|
|
|
|
insert into x values (4,44);
|
|
|
|
insert into x values (5,null);
|
|
|
|
|
|
|
|
create temp table y (y1 int, y2 int);
|
|
|
|
insert into y values (1,111);
|
|
|
|
insert into y values (2,222);
|
|
|
|
insert into y values (3,333);
|
|
|
|
insert into y values (4,null);
|
|
|
|
|
|
|
|
select * from x;
|
|
|
|
select * from y;
|
|
|
|
|
|
|
|
select * from x left join y on (x1 = y1 and x2 is not null);
|
|
|
|
select * from x left join y on (x1 = y1 and y2 is not null);
|
|
|
|
|
|
|
|
select * from (x left join y on (x1 = y1)) left join x xx(xx1,xx2)
|
|
|
|
on (x1 = xx1);
|
|
|
|
select * from (x left join y on (x1 = y1)) left join x xx(xx1,xx2)
|
|
|
|
on (x1 = xx1 and x2 is not null);
|
|
|
|
select * from (x left join y on (x1 = y1)) left join x xx(xx1,xx2)
|
|
|
|
on (x1 = xx1 and y2 is not null);
|
|
|
|
select * from (x left join y on (x1 = y1)) left join x xx(xx1,xx2)
|
|
|
|
on (x1 = xx1 and xx2 is not null);
|
|
|
|
-- these should NOT give the same answers as above
|
|
|
|
select * from (x left join y on (x1 = y1)) left join x xx(xx1,xx2)
|
|
|
|
on (x1 = xx1) where (x2 is not null);
|
|
|
|
select * from (x left join y on (x1 = y1)) left join x xx(xx1,xx2)
|
|
|
|
on (x1 = xx1) where (y2 is not null);
|
|
|
|
select * from (x left join y on (x1 = y1)) left join x xx(xx1,xx2)
|
|
|
|
on (x1 = xx1) where (xx2 is not null);
|
|
|
|
|
2003-08-07 21:20:24 +02:00
|
|
|
--
|
|
|
|
-- regression test: check for bug with propagation of implied equality
|
|
|
|
-- to outside an IN
|
|
|
|
--
|
|
|
|
select count(*) from tenk1 a where unique1 in
|
|
|
|
(select unique1 from tenk1 b join tenk1 c using (unique1)
|
|
|
|
where b.unique2 = 42);
|
|
|
|
|
Restructure code that is responsible for ensuring that clauseless joins are
considered when it is necessary to do so because of a join-order restriction
(that is, an outer-join or IN-subselect construct). The former coding was a
bit ad-hoc and inconsistent, and it missed some cases, as exposed by Mario
Weilguni's recent bug report. His specific problem was that an IN could be
turned into a "clauseless" join due to constant-propagation removing the IN's
joinclause, and if the IN's subselect involved more than one relation and
there was more than one such IN linking to the same upper relation, then the
only valid join orders involve "bushy" plans but we would fail to consider the
specific paths needed to get there. (See the example case added to the join
regression test.) On examining the code I wonder if there weren't some other
problem cases too; in particular it seems that GEQO was defending against a
different set of corner cases than the main planner was. There was also an
efficiency problem, in that when we did realize we needed a clauseless join
because of an IN, we'd consider clauseless joins against every other relation
whether this was sensible or not. It seems a better design is to use the
outer-join and in-clause lists as a backup heuristic, just as the rule of
joining only where there are joinclauses is a heuristic: we'll join two
relations if they have a usable joinclause *or* this might be necessary to
satisfy an outer-join or IN-clause join order restriction. I refactored the
code to have just one place considering this instead of three, and made sure
that it covered all the cases that any of them had been considering.
Backpatch as far as 8.1 (which has only the IN-clause form of the disease).
By rights 8.0 and 7.4 should have the bug too, but they accidentally fail
to fail, because the joininfo structure used in those releases preserves some
memory of there having once been a joinclause between the inner and outer
sides of an IN, and so it leads the code in the right direction anyway.
I'll be conservative and not touch them.
2007-02-16 01:14:01 +01:00
|
|
|
--
|
|
|
|
-- regression test: check for failure to generate a plan with multiple
|
|
|
|
-- degenerate IN clauses
|
|
|
|
--
|
|
|
|
select count(*) from tenk1 x where
|
|
|
|
x.unique1 in (select a.f1 from int4_tbl a,float8_tbl b where a.f1=b.f1) and
|
|
|
|
x.unique1 = 0 and
|
|
|
|
x.unique1 in (select aa.f1 from int4_tbl aa,float8_tbl bb where aa.f1=bb.f1);
|
|
|
|
|
2009-07-19 22:32:48 +02:00
|
|
|
-- try that with GEQO too
|
|
|
|
begin;
|
|
|
|
set geqo = on;
|
|
|
|
set geqo_threshold = 2;
|
|
|
|
select count(*) from tenk1 x where
|
|
|
|
x.unique1 in (select a.f1 from int4_tbl a,float8_tbl b where a.f1=b.f1) and
|
|
|
|
x.unique1 = 0 and
|
|
|
|
x.unique1 in (select aa.f1 from int4_tbl aa,float8_tbl bb where aa.f1=bb.f1);
|
|
|
|
rollback;
|
|
|
|
|
2003-02-10 18:08:50 +01:00
|
|
|
|
1999-02-23 08:27:13 +01:00
|
|
|
--
|
|
|
|
-- Clean up
|
|
|
|
--
|
|
|
|
|
2002-03-12 01:52:10 +01:00
|
|
|
DROP TABLE t1;
|
|
|
|
DROP TABLE t2;
|
|
|
|
DROP TABLE t3;
|
|
|
|
|
2000-02-15 04:31:33 +01:00
|
|
|
DROP TABLE J1_TBL;
|
|
|
|
DROP TABLE J2_TBL;
|
2005-04-07 03:51:41 +02:00
|
|
|
|
|
|
|
-- Both DELETE and UPDATE allow the specification of additional tables
|
|
|
|
-- to "join" against to determine which rows should be modified.
|
|
|
|
|
|
|
|
CREATE TEMP TABLE t1 (a int, b int);
|
|
|
|
CREATE TEMP TABLE t2 (a int, b int);
|
|
|
|
CREATE TEMP TABLE t3 (x int, y int);
|
|
|
|
|
|
|
|
INSERT INTO t1 VALUES (5, 10);
|
|
|
|
INSERT INTO t1 VALUES (15, 20);
|
|
|
|
INSERT INTO t1 VALUES (100, 100);
|
|
|
|
INSERT INTO t1 VALUES (200, 1000);
|
|
|
|
INSERT INTO t2 VALUES (200, 2000);
|
|
|
|
INSERT INTO t3 VALUES (5, 20);
|
|
|
|
INSERT INTO t3 VALUES (6, 7);
|
|
|
|
INSERT INTO t3 VALUES (7, 8);
|
|
|
|
INSERT INTO t3 VALUES (500, 100);
|
|
|
|
|
|
|
|
DELETE FROM t3 USING t1 table1 WHERE t3.x = table1.a;
|
|
|
|
SELECT * FROM t3;
|
|
|
|
DELETE FROM t3 USING t1 JOIN t2 USING (a) WHERE t3.x > t1.a;
|
|
|
|
SELECT * FROM t3;
|
|
|
|
DELETE FROM t3 USING t3 t3_other WHERE t3.x = t3_other.x AND t3.y = t3_other.y;
|
2005-04-07 17:23:06 +02:00
|
|
|
SELECT * FROM t3;
|
2006-03-17 20:38:12 +01:00
|
|
|
|
2009-08-13 19:14:38 +02:00
|
|
|
-- Test join against inheritance tree
|
|
|
|
|
|
|
|
create temp table t2a () inherits (t2);
|
|
|
|
|
|
|
|
insert into t2a values (200, 2001);
|
|
|
|
|
|
|
|
select * from t1 left join t2 on (t1.a = t2.a);
|
|
|
|
|
2006-03-17 20:38:12 +01:00
|
|
|
--
|
|
|
|
-- regression test for 8.1 merge right join bug
|
|
|
|
--
|
|
|
|
|
|
|
|
CREATE TEMP TABLE tt1 ( tt1_id int4, joincol int4 );
|
|
|
|
INSERT INTO tt1 VALUES (1, 11);
|
|
|
|
INSERT INTO tt1 VALUES (2, NULL);
|
|
|
|
|
|
|
|
CREATE TEMP TABLE tt2 ( tt2_id int4, joincol int4 );
|
|
|
|
INSERT INTO tt2 VALUES (21, 11);
|
|
|
|
INSERT INTO tt2 VALUES (22, 11);
|
|
|
|
|
|
|
|
set enable_hashjoin to off;
|
|
|
|
set enable_nestloop to off;
|
|
|
|
|
|
|
|
-- these should give the same results
|
|
|
|
|
|
|
|
select tt1.*, tt2.* from tt1 left join tt2 on tt1.joincol = tt2.joincol;
|
|
|
|
|
|
|
|
select tt1.*, tt2.* from tt2 right join tt1 on tt1.joincol = tt2.joincol;
|
2007-05-23 01:23:58 +02:00
|
|
|
|
|
|
|
reset enable_hashjoin;
|
|
|
|
reset enable_nestloop;
|
|
|
|
|
|
|
|
--
|
|
|
|
-- regression test for 8.2 bug with improper re-ordering of left joins
|
|
|
|
--
|
|
|
|
|
|
|
|
create temp table tt3(f1 int, f2 text);
|
|
|
|
insert into tt3 select x, repeat('xyzzy', 100) from generate_series(1,10000) x;
|
|
|
|
create index tt3i on tt3(f1);
|
|
|
|
analyze tt3;
|
|
|
|
|
|
|
|
create temp table tt4(f1 int);
|
|
|
|
insert into tt4 values (0),(1),(9999);
|
|
|
|
analyze tt4;
|
|
|
|
|
|
|
|
SELECT a.f1
|
|
|
|
FROM tt4 a
|
|
|
|
LEFT JOIN (
|
|
|
|
SELECT b.f1
|
|
|
|
FROM tt3 b LEFT JOIN tt3 c ON (b.f1 = c.f1)
|
|
|
|
WHERE c.f1 IS NULL
|
|
|
|
) AS d ON (a.f1 = d.f1)
|
|
|
|
WHERE d.f1 IS NULL;
|
2007-07-31 21:53:37 +02:00
|
|
|
|
|
|
|
--
|
|
|
|
-- regression test for problems of the sort depicted in bug #3494
|
|
|
|
--
|
|
|
|
|
|
|
|
create temp table tt5(f1 int, f2 int);
|
|
|
|
create temp table tt6(f1 int, f2 int);
|
|
|
|
|
|
|
|
insert into tt5 values(1, 10);
|
|
|
|
insert into tt5 values(1, 11);
|
|
|
|
|
|
|
|
insert into tt6 values(1, 9);
|
|
|
|
insert into tt6 values(1, 2);
|
|
|
|
insert into tt6 values(2, 9);
|
|
|
|
|
|
|
|
select * from tt5,tt6 where tt5.f1 = tt6.f1 and tt5.f1 = tt5.f2 - tt6.f2;
|
2007-08-31 03:44:06 +02:00
|
|
|
|
|
|
|
--
|
|
|
|
-- regression test for problems of the sort depicted in bug #3588
|
|
|
|
--
|
|
|
|
|
|
|
|
create temp table xx (pkxx int);
|
|
|
|
create temp table yy (pkyy int, pkxx int);
|
|
|
|
|
|
|
|
insert into xx values (1);
|
|
|
|
insert into xx values (2);
|
|
|
|
insert into xx values (3);
|
|
|
|
|
|
|
|
insert into yy values (101, 1);
|
|
|
|
insert into yy values (201, 2);
|
|
|
|
insert into yy values (301, NULL);
|
|
|
|
|
|
|
|
select yy.pkyy as yy_pkyy, yy.pkxx as yy_pkxx, yya.pkyy as yya_pkyy,
|
|
|
|
xxa.pkxx as xxa_pkxx, xxb.pkxx as xxb_pkxx
|
|
|
|
from yy
|
|
|
|
left join (SELECT * FROM yy where pkyy = 101) as yya ON yy.pkyy = yya.pkyy
|
|
|
|
left join xx xxa on yya.pkxx = xxa.pkxx
|
|
|
|
left join xx xxb on coalesce (xxa.pkxx, 1) = xxb.pkxx;
|
Fix some planner issues found while investigating Kevin Grittner's report
of poorer planning in 8.3 than 8.2:
1. After pushing a constant across an outer join --- ie, given
"a LEFT JOIN b ON (a.x = b.y) WHERE a.x = 42", we can deduce that b.y is
sort of equal to 42, in the sense that we needn't fetch any b rows where
it isn't 42 --- loop to see if any additional deductions can be made.
Previous releases did that by recursing, but I had mistakenly thought that
this was no longer necessary given the EquivalenceClass machinery.
2. Allow pushing constants across outer join conditions even if the
condition is outerjoin_delayed due to a lower outer join. This is safe
as long as the condition is strict and we re-test it at the upper join.
3. Keep the outer-join clause even if we successfully push a constant
across it. This is *necessary* in the outerjoin_delayed case, but
even in the simple case, it seems better to do this to ensure that the
join search order heuristics will consider the join as reasonable to
make. Mark such a clause as having selectivity 1.0, though, since it's
not going to eliminate very many rows after application of the constant
condition.
4. Tweak have_relevant_eclass_joinclause to report that two relations
are joinable when they have vars that are equated to the same constant.
We won't actually generate any joinclause from such an EquivalenceClass,
but again it seems that in such a case it's a good idea to consider
the join as worth costing out.
5. Fix a bug in select_mergejoin_clauses that was exposed by these
changes: we have to reject candidate mergejoin clauses if either side was
equated to a constant, because we can't construct a canonical pathkey list
for such a clause. This is an implementation restriction that might be
worth fixing someday, but it doesn't seem critical to get it done for 8.3.
2008-01-09 21:42:29 +01:00
|
|
|
|
|
|
|
--
|
|
|
|
-- regression test for improper pushing of constants across outer-join clauses
|
|
|
|
-- (as seen in early 8.2.x releases)
|
|
|
|
--
|
|
|
|
|
|
|
|
create temp table zt1 (f1 int primary key);
|
|
|
|
create temp table zt2 (f2 int primary key);
|
|
|
|
create temp table zt3 (f3 int primary key);
|
|
|
|
insert into zt1 values(53);
|
|
|
|
insert into zt2 values(53);
|
|
|
|
|
|
|
|
select * from
|
|
|
|
zt2 left join zt3 on (f2 = f3)
|
|
|
|
left join zt1 on (f3 = f1)
|
|
|
|
where f2 = 53;
|
|
|
|
|
|
|
|
create temp view zv1 as select *,'dummy'::text AS junk from zt1;
|
|
|
|
|
|
|
|
select * from
|
|
|
|
zt2 left join zt3 on (f2 = f3)
|
|
|
|
left join zv1 on (f3 = f1)
|
|
|
|
where f2 = 53;
|
2008-06-27 22:54:37 +02:00
|
|
|
|
|
|
|
--
|
|
|
|
-- regression test for improper extraction of OR indexqual conditions
|
|
|
|
-- (as seen in early 8.3.x releases)
|
|
|
|
--
|
|
|
|
|
|
|
|
select a.unique2, a.ten, b.tenthous, b.unique2, b.hundred
|
|
|
|
from tenk1 a left join tenk1 b on a.unique2 = b.tenthous
|
|
|
|
where a.unique1 = 42 and
|
|
|
|
((b.unique2 is null and a.ten = 2) or b.hundred = 3);
|
2009-02-25 04:30:38 +01:00
|
|
|
|
|
|
|
--
|
|
|
|
-- test proper positioning of one-time quals in EXISTS (8.4devel bug)
|
|
|
|
--
|
|
|
|
prepare foo(bool) as
|
|
|
|
select count(*) from tenk1 a left join tenk1 b
|
|
|
|
on (a.unique2 = b.unique1 and exists
|
|
|
|
(select 1 from tenk1 c where c.thousand = b.unique2 and $1));
|
|
|
|
execute foo(true);
|
|
|
|
execute foo(false);
|
2009-07-18 01:19:34 +02:00
|
|
|
|
|
|
|
--
|
|
|
|
-- test for sane behavior with noncanonical merge clauses, per bug #4926
|
|
|
|
--
|
|
|
|
|
|
|
|
begin;
|
|
|
|
|
|
|
|
set enable_mergejoin = 1;
|
|
|
|
set enable_hashjoin = 0;
|
|
|
|
set enable_nestloop = 0;
|
|
|
|
|
|
|
|
create temp table a (i integer);
|
|
|
|
create temp table b (x integer, y integer);
|
|
|
|
|
|
|
|
select * from a left join b on i = x and i = y and x = i;
|
|
|
|
|
|
|
|
rollback;
|
Fix subquery pullup to wrap a PlaceHolderVar around the entire RowExpr
that's generated for a whole-row Var referencing the subquery, when the
subquery is in the nullable side of an outer join. The previous coding
instead put PlaceHolderVars around the elements of the RowExpr. The effect
was that when the outer join made the subquery outputs go to null, the
whole-row Var produced ROW(NULL,NULL,...) rather than just NULL. There
are arguments afoot about whether those things ought to be semantically
indistinguishable, but for the moment they are not entirely so, and the
planner needs to take care that its machinations preserve the difference.
Per bug #5025.
Making this feasible required refactoring ResolveNew() to allow more caller
control over what is substituted for a Var. I chose to make ResolveNew()
a wrapper around a new general-purpose function replace_rte_variables().
I also fixed the ancient bogosity that ResolveNew might fail to set
a query's hasSubLinks field after inserting a SubLink in it. Although
all current callers make sure that happens anyway, we've had bugs of that
sort before, and it seemed like a good time to install a proper solution.
Back-patch to 8.4. The problem can be demonstrated clear back to 8.0,
but the fix would be too invasive in earlier branches; not to mention
that people may be depending on the subtly-incorrect behavior. The
8.4 series is new enough that fixing this probably won't cause complaints,
but it might in older branches. Also, 8.4 shows the incorrect behavior
in more cases than older branches do, because it is able to flatten
subqueries in more cases.
2009-09-02 19:52:24 +02:00
|
|
|
|
|
|
|
--
|
|
|
|
-- test NULL behavior of whole-row Vars, per bug #5025
|
|
|
|
--
|
|
|
|
select t1.q2, count(t2.*)
|
|
|
|
from int8_tbl t1 left join int8_tbl t2 on (t1.q2 = t2.q1)
|
|
|
|
group by t1.q2 order by 1;
|
|
|
|
|
|
|
|
select t1.q2, count(t2.*)
|
|
|
|
from int8_tbl t1 left join (select * from int8_tbl) t2 on (t1.q2 = t2.q1)
|
|
|
|
group by t1.q2 order by 1;
|
|
|
|
|
|
|
|
select t1.q2, count(t2.*)
|
|
|
|
from int8_tbl t1 left join (select * from int8_tbl offset 0) t2 on (t1.q2 = t2.q1)
|
|
|
|
group by t1.q2 order by 1;
|
|
|
|
|
|
|
|
select t1.q2, count(t2.*)
|
|
|
|
from int8_tbl t1 left join
|
|
|
|
(select q1, case when q2=1 then 1 else q2 end as q2 from int8_tbl) t2
|
|
|
|
on (t1.q2 = t2.q1)
|
|
|
|
group by t1.q2 order by 1;
|
2010-01-06 00:25:36 +01:00
|
|
|
|
2010-09-28 18:08:56 +02:00
|
|
|
--
|
|
|
|
-- test incorrect failure to NULL pulled-up subexpressions
|
|
|
|
--
|
|
|
|
begin;
|
|
|
|
|
|
|
|
create temp table a (
|
|
|
|
code char not null,
|
|
|
|
constraint a_pk primary key (code)
|
|
|
|
);
|
|
|
|
create temp table b (
|
|
|
|
a char not null,
|
|
|
|
num integer not null,
|
|
|
|
constraint b_pk primary key (a, num)
|
|
|
|
);
|
|
|
|
create temp table c (
|
|
|
|
name char not null,
|
|
|
|
a char,
|
|
|
|
constraint c_pk primary key (name)
|
|
|
|
);
|
|
|
|
|
|
|
|
insert into a (code) values ('p');
|
|
|
|
insert into a (code) values ('q');
|
|
|
|
insert into b (a, num) values ('p', 1);
|
|
|
|
insert into b (a, num) values ('p', 2);
|
|
|
|
insert into c (name, a) values ('A', 'p');
|
|
|
|
insert into c (name, a) values ('B', 'q');
|
|
|
|
insert into c (name, a) values ('C', null);
|
|
|
|
|
|
|
|
select c.name, ss.code, ss.b_cnt, ss.const
|
|
|
|
from c left join
|
|
|
|
(select a.code, coalesce(b_grp.cnt, 0) as b_cnt, -1 as const
|
|
|
|
from a left join
|
|
|
|
(select count(1) as cnt, b.a from b group by b.a) as b_grp
|
|
|
|
on a.code = b_grp.a
|
|
|
|
) as ss
|
|
|
|
on (c.a = ss.code)
|
|
|
|
order by c.name;
|
|
|
|
|
|
|
|
rollback;
|
|
|
|
|
2011-08-09 06:48:51 +02:00
|
|
|
--
|
|
|
|
-- test incorrect handling of placeholders that only appear in targetlists,
|
|
|
|
-- per bug #6154
|
|
|
|
--
|
|
|
|
SELECT * FROM
|
|
|
|
( SELECT 1 as key1 ) sub1
|
|
|
|
LEFT JOIN
|
|
|
|
( SELECT sub3.key3, sub4.value2, COALESCE(sub4.value2, 66) as value3 FROM
|
|
|
|
( SELECT 1 as key3 ) sub3
|
|
|
|
LEFT JOIN
|
|
|
|
( SELECT sub5.key5, COALESCE(sub6.value1, 1) as value2 FROM
|
|
|
|
( SELECT 1 as key5 ) sub5
|
|
|
|
LEFT JOIN
|
|
|
|
( SELECT 2 as key6, 42 as value1 ) sub6
|
|
|
|
ON sub5.key5 = sub6.key6
|
|
|
|
) sub4
|
|
|
|
ON sub4.key5 = sub3.key3
|
|
|
|
) sub2
|
|
|
|
ON sub1.key1 = sub2.key3;
|
|
|
|
|
|
|
|
-- test the path using join aliases, too
|
|
|
|
SELECT * FROM
|
|
|
|
( SELECT 1 as key1 ) sub1
|
|
|
|
LEFT JOIN
|
|
|
|
( SELECT sub3.key3, value2, COALESCE(value2, 66) as value3 FROM
|
|
|
|
( SELECT 1 as key3 ) sub3
|
|
|
|
LEFT JOIN
|
|
|
|
( SELECT sub5.key5, COALESCE(sub6.value1, 1) as value2 FROM
|
|
|
|
( SELECT 1 as key5 ) sub5
|
|
|
|
LEFT JOIN
|
|
|
|
( SELECT 2 as key6, 42 as value1 ) sub6
|
|
|
|
ON sub5.key5 = sub6.key6
|
|
|
|
) sub4
|
|
|
|
ON sub4.key5 = sub3.key3
|
|
|
|
) sub2
|
|
|
|
ON sub1.key1 = sub2.key3;
|
|
|
|
|
2011-11-03 05:50:58 +01:00
|
|
|
--
|
|
|
|
-- test case where a PlaceHolderVar is used as a nestloop parameter
|
|
|
|
--
|
|
|
|
|
|
|
|
EXPLAIN (COSTS OFF)
|
|
|
|
SELECT qq, unique1
|
|
|
|
FROM
|
|
|
|
( SELECT COALESCE(q1, 0) AS qq FROM int8_tbl a ) AS ss1
|
|
|
|
FULL OUTER JOIN
|
|
|
|
( SELECT COALESCE(q2, -1) AS qq FROM int8_tbl b ) AS ss2
|
|
|
|
USING (qq)
|
|
|
|
INNER JOIN tenk1 c ON qq = unique2;
|
|
|
|
|
|
|
|
SELECT qq, unique1
|
|
|
|
FROM
|
|
|
|
( SELECT COALESCE(q1, 0) AS qq FROM int8_tbl a ) AS ss1
|
|
|
|
FULL OUTER JOIN
|
|
|
|
( SELECT COALESCE(q2, -1) AS qq FROM int8_tbl b ) AS ss2
|
|
|
|
USING (qq)
|
|
|
|
INNER JOIN tenk1 c ON qq = unique2;
|
|
|
|
|
2012-03-24 21:21:39 +01:00
|
|
|
--
|
|
|
|
-- test case where a PlaceHolderVar is propagated into a subquery
|
|
|
|
--
|
|
|
|
|
|
|
|
explain (costs off)
|
|
|
|
select * from
|
|
|
|
int8_tbl t1 left join
|
|
|
|
(select q1 as x, 42 as y from int8_tbl t2) ss
|
|
|
|
on t1.q2 = ss.x
|
|
|
|
where
|
|
|
|
1 = (select 1 from int8_tbl t3 where ss.y is not null limit 1)
|
|
|
|
order by 1,2;
|
|
|
|
|
|
|
|
select * from
|
|
|
|
int8_tbl t1 left join
|
|
|
|
(select q1 as x, 42 as y from int8_tbl t2) ss
|
|
|
|
on t1.q2 = ss.x
|
|
|
|
where
|
|
|
|
1 = (select 1 from int8_tbl t3 where ss.y is not null limit 1)
|
|
|
|
order by 1,2;
|
|
|
|
|
2010-01-06 00:25:36 +01:00
|
|
|
--
|
|
|
|
-- test the corner cases FULL JOIN ON TRUE and FULL JOIN ON FALSE
|
|
|
|
--
|
|
|
|
select * from int4_tbl a full join int4_tbl b on true;
|
|
|
|
select * from int4_tbl a full join int4_tbl b on false;
|
2010-03-22 14:57:16 +01:00
|
|
|
|
2012-04-13 21:32:34 +02:00
|
|
|
--
|
|
|
|
-- test for ability to use a cartesian join when necessary
|
|
|
|
--
|
|
|
|
|
|
|
|
explain (costs off)
|
|
|
|
select * from
|
|
|
|
tenk1 join int4_tbl on f1 = twothousand,
|
|
|
|
int4(sin(1)) q1,
|
|
|
|
int4(sin(0)) q2
|
|
|
|
where q1 = thousand or q2 = thousand;
|
|
|
|
|
|
|
|
explain (costs off)
|
|
|
|
select * from
|
|
|
|
tenk1 join int4_tbl on f1 = twothousand,
|
|
|
|
int4(sin(1)) q1,
|
|
|
|
int4(sin(0)) q2
|
|
|
|
where thousand = (q1 + q2);
|
|
|
|
|
Extract restriction OR clauses whether or not they are indexable.
It's possible to extract a restriction OR clause from a join clause that
has the form of an OR-of-ANDs, if each sub-AND includes a clause that
mentions only one specific relation. While PG has been aware of that idea
for many years, the code previously only did it if it could extract an
indexable OR clause. On reflection, though, that seems a silly limitation:
adding a restriction clause can be a win by reducing the number of rows
that have to be filtered at the join step, even if we have to test the
clause as a plain filter clause during the scan. This should be especially
useful for foreign tables, where the change can cut the number of rows that
have to be retrieved from the foreign server; but testing shows it can win
even on local tables. Per a suggestion from Robert Haas.
As a heuristic, I made the code accept an extracted restriction clause
if its estimated selectivity is less than 0.9, which will probably result
in accepting extracted clauses just about always. We might need to tweak
that later based on experience.
Since the code no longer has even a weak connection to Path creation,
remove orindxpath.c and create a new file optimizer/util/orclauses.c.
There's some additional janitorial cleanup of now-dead code that needs
to happen, but it seems like that's a fit subject for a separate commit.
2013-12-30 18:24:37 +01:00
|
|
|
--
|
|
|
|
-- test extraction of restriction OR clauses from join OR clause
|
|
|
|
-- (we used to only do this for indexable clauses)
|
|
|
|
--
|
|
|
|
|
|
|
|
explain (costs off)
|
|
|
|
select * from tenk1 a join tenk1 b on
|
|
|
|
(a.unique1 = 1 and b.unique1 = 2) or (a.unique2 = 3 and b.hundred = 4);
|
|
|
|
explain (costs off)
|
|
|
|
select * from tenk1 a join tenk1 b on
|
|
|
|
(a.unique1 = 1 and b.unique1 = 2) or (a.unique2 = 3 and b.ten = 4);
|
|
|
|
|
Revise parameterized-path mechanism to fix assorted issues.
This patch adjusts the treatment of parameterized paths so that all paths
with the same parameterization (same set of required outer rels) for the
same relation will have the same rowcount estimate. We cache the rowcount
estimates to ensure that property, and hopefully save a few cycles too.
Doing this makes it practical for add_path_precheck to operate without
a rowcount estimate: it need only assume that paths with different
parameterizations never dominate each other, which is close enough to
true anyway for coarse filtering, because normally a more-parameterized
path should yield fewer rows thanks to having more join clauses to apply.
In add_path, we do the full nine yards of comparing rowcount estimates
along with everything else, so that we can discard parameterized paths that
don't actually have an advantage. This fixes some issues I'd found with
add_path rejecting parameterized paths on the grounds that they were more
expensive than not-parameterized ones, even though they yielded many fewer
rows and hence would be cheaper once subsequent joining was considered.
To make the same-rowcounts assumption valid, we have to require that any
parameterized path enforce *all* join clauses that could be obtained from
the particular set of outer rels, even if not all of them are useful for
indexing. This is required at both base scans and joins. It's a good
thing anyway since the net impact is that join quals are checked at the
lowest practical level in the join tree. Hence, discard the original
rather ad-hoc mechanism for choosing parameterization joinquals, and build
a better one that has a more principled rule for when clauses can be moved.
The original rule was actually buggy anyway for lack of knowledge about
which relations are part of an outer join's outer side; getting this right
requires adding an outer_relids field to RestrictInfo.
2012-04-19 21:52:46 +02:00
|
|
|
--
|
|
|
|
-- test placement of movable quals in a parameterized join tree
|
|
|
|
--
|
|
|
|
|
|
|
|
explain (costs off)
|
|
|
|
select * from tenk1 t1 left join
|
|
|
|
(tenk1 t2 join tenk1 t3 on t2.thousand = t3.unique2)
|
|
|
|
on t1.hundred = t2.hundred and t1.ten = t3.ten
|
|
|
|
where t1.unique1 = 1;
|
|
|
|
|
|
|
|
explain (costs off)
|
|
|
|
select * from tenk1 t1 left join
|
|
|
|
(tenk1 t2 join tenk1 t3 on t2.thousand = t3.unique2)
|
|
|
|
on t1.hundred = t2.hundred and t1.ten + t2.ten = t3.ten
|
|
|
|
where t1.unique1 = 1;
|
|
|
|
|
|
|
|
explain (costs off)
|
|
|
|
select count(*) from
|
|
|
|
tenk1 a join tenk1 b on a.unique1 = b.unique2
|
|
|
|
left join tenk1 c on a.unique2 = b.unique1 and c.thousand = a.thousand
|
|
|
|
join int4_tbl on b.thousand = f1;
|
|
|
|
|
|
|
|
select count(*) from
|
|
|
|
tenk1 a join tenk1 b on a.unique1 = b.unique2
|
|
|
|
left join tenk1 c on a.unique2 = b.unique1 and c.thousand = a.thousand
|
|
|
|
join int4_tbl on b.thousand = f1;
|
|
|
|
|
|
|
|
explain (costs off)
|
|
|
|
select b.unique1 from
|
|
|
|
tenk1 a join tenk1 b on a.unique1 = b.unique2
|
|
|
|
left join tenk1 c on b.unique1 = 42 and c.thousand = a.thousand
|
|
|
|
join int4_tbl i1 on b.thousand = f1
|
|
|
|
right join int4_tbl i2 on i2.f1 = b.tenthous
|
|
|
|
order by 1;
|
|
|
|
|
|
|
|
select b.unique1 from
|
|
|
|
tenk1 a join tenk1 b on a.unique1 = b.unique2
|
|
|
|
left join tenk1 c on b.unique1 = 42 and c.thousand = a.thousand
|
|
|
|
join int4_tbl i1 on b.thousand = f1
|
|
|
|
right join int4_tbl i2 on i2.f1 = b.tenthous
|
|
|
|
order by 1;
|
|
|
|
|
Postpone creation of pathkeys lists to fix bug #8049.
This patch gets rid of the concept of, and infrastructure for,
non-canonical PathKeys; we now only ever create canonical pathkey lists.
The need for non-canonical pathkeys came from the desire to have
grouping_planner initialize query_pathkeys and related pathkey lists before
calling query_planner. However, since query_planner didn't actually *do*
anything with those lists before they'd been made canonical, we can get rid
of the whole mess by just not creating the lists at all until the point
where we formerly canonicalized them.
There are several ways in which we could implement that without making
query_planner itself deal with grouping/sorting features (which are
supposed to be the province of grouping_planner). I chose to add a
callback function to query_planner's API; other alternatives would have
required adding more fields to PlannerInfo, which while not bad in itself
would create an ABI break for planner-related plugins in the 9.2 release
series. This still breaks ABI for anything that calls query_planner
directly, but it seems somewhat unlikely that there are any such plugins.
I had originally conceived of this change as merely a step on the way to
fixing bug #8049 from Teun Hoogendoorn; but it turns out that this fixes
that bug all by itself, as per the added regression test. The reason is
that now get_eclass_for_sort_expr is adding the ORDER BY expression at the
end of EquivalenceClass creation not the start, and so anything that is in
a multi-member EquivalenceClass has already been created with correct
em_nullable_relids. I am suspicious that there are related scenarios in
which we still need to teach get_eclass_for_sort_expr to compute correct
nullable_relids, but am not eager to risk destabilizing either 9.2 or 9.3
to fix bugs that are only hypothetical. So for the moment, do this and
stop here.
Back-patch to 9.2 but not to earlier branches, since they don't exhibit
this bug for lack of join-clause-movement logic that depends on
em_nullable_relids being correct. (We might have to revisit that choice
if any related bugs turn up.) In 9.2, don't change the signature of
make_pathkeys_for_sortclauses nor remove canonicalize_pathkeys, so as
not to risk more plugin breakage than we have to.
2013-04-29 20:49:01 +02:00
|
|
|
explain (costs off)
|
|
|
|
select * from
|
|
|
|
(
|
|
|
|
select unique1, q1, coalesce(unique1, -1) + q1 as fault
|
|
|
|
from int8_tbl left join tenk1 on (q2 = unique2)
|
|
|
|
) ss
|
|
|
|
where fault = 122
|
|
|
|
order by fault;
|
|
|
|
|
|
|
|
select * from
|
|
|
|
(
|
|
|
|
select unique1, q1, coalesce(unique1, -1) + q1 as fault
|
|
|
|
from int8_tbl left join tenk1 on (q2 = unique2)
|
|
|
|
) ss
|
|
|
|
where fault = 122
|
|
|
|
order by fault;
|
|
|
|
|
Fix planning of non-strict equivalence clauses above outer joins.
If a potential equivalence clause references a variable from the nullable
side of an outer join, the planner needs to take care that derived clauses
are not pushed to below the outer join; else they may use the wrong value
for the variable. (The problem arises only with non-strict clauses, since
if an upper clause can be proven strict then the outer join will get
simplified to a plain join.) The planner attempted to prevent this type
of error by checking that potential equivalence clauses aren't
outerjoin-delayed as a whole, but actually we have to check each side
separately, since the two sides of the clause will get moved around
separately if it's treated as an equivalence. Bugs of this type can be
demonstrated as far back as 7.4, even though releases before 8.3 had only
a very ad-hoc notion of equivalence clauses.
In addition, we neglected to account for the possibility that such clauses
might have nonempty nullable_relids even when not outerjoin-delayed; so the
equivalence-class machinery lacked logic to compute correct nullable_relids
values for clauses it constructs. This oversight was harmless before 9.2
because we were only using RestrictInfo.nullable_relids for OR clauses;
but as of 9.2 it could result in pushing constructed equivalence clauses
to incorrect places. (This accounts for bug #7604 from Bill MacArthur.)
Fix the first problem by adding a new test check_equivalence_delay() in
distribute_qual_to_rels, and fix the second one by adding code in
equivclass.c and called functions to set correct nullable_relids for
generated clauses. Although I believe the second part of this is not
currently necessary before 9.2, I chose to back-patch it anyway, partly to
keep the logic similar across branches and partly because it seems possible
we might find other reasons why we need valid values of nullable_relids in
the older branches.
Add regression tests illustrating these problems. In 9.0 and up, also
add test cases checking that we can push constants through outer joins,
since we've broken that optimization before and I nearly broke it again
with an overly simplistic patch for this problem.
2012-10-18 18:28:45 +02:00
|
|
|
--
|
|
|
|
-- test handling of potential equivalence clauses above outer joins
|
|
|
|
--
|
|
|
|
|
|
|
|
explain (costs off)
|
|
|
|
select q1, unique2, thousand, hundred
|
|
|
|
from int8_tbl a left join tenk1 b on q1 = unique2
|
|
|
|
where coalesce(thousand,123) = q1 and q1 = coalesce(hundred,123);
|
|
|
|
|
|
|
|
select q1, unique2, thousand, hundred
|
|
|
|
from int8_tbl a left join tenk1 b on q1 = unique2
|
|
|
|
where coalesce(thousand,123) = q1 and q1 = coalesce(hundred,123);
|
|
|
|
|
|
|
|
explain (costs off)
|
|
|
|
select f1, unique2, case when unique2 is null then f1 else 0 end
|
|
|
|
from int4_tbl a left join tenk1 b on f1 = unique2
|
|
|
|
where (case when unique2 is null then f1 else 0 end) = 0;
|
|
|
|
|
|
|
|
select f1, unique2, case when unique2 is null then f1 else 0 end
|
|
|
|
from int4_tbl a left join tenk1 b on f1 = unique2
|
|
|
|
where (case when unique2 is null then f1 else 0 end) = 0;
|
|
|
|
|
Compute correct em_nullable_relids in get_eclass_for_sort_expr().
Bug #8591 from Claudio Freire demonstrates that get_eclass_for_sort_expr
must be able to compute valid em_nullable_relids for any new equivalence
class members it creates. I'd worried about this in the commit message
for db9f0e1d9a4a0842c814a464cdc9758c3f20b96c, but claimed that it wasn't a
problem because multi-member ECs should already exist when it runs. That
is transparently wrong, though, because this function is also called by
initialize_mergeclause_eclasses, which runs during deconstruct_jointree.
The example given in the bug report (which the new regression test item
is based upon) fails because the COALESCE() expression is first seen by
initialize_mergeclause_eclasses rather than process_equivalence.
Fixing this requires passing the appropriate nullable_relids set to
get_eclass_for_sort_expr, and it requires new code to compute that set
for top-level expressions such as ORDER BY, GROUP BY, etc. We store
the top-level nullable_relids in a new field in PlannerInfo to avoid
computing it many times. In the back branches, I've added the new
field at the end of the struct to minimize ABI breakage for planner
plugins. There doesn't seem to be a good alternative to changing
get_eclass_for_sort_expr's API signature, though. There probably aren't
any third-party extensions calling that function directly; moreover,
if there are, they probably need to think about what to pass for
nullable_relids anyway.
Back-patch to 9.2, like the previous patch in this area.
2013-11-15 22:46:18 +01:00
|
|
|
--
|
|
|
|
-- another case with equivalence clauses above outer joins (bug #8591)
|
|
|
|
--
|
|
|
|
|
|
|
|
explain (costs off)
|
|
|
|
select a.unique1, b.unique1, c.unique1, coalesce(b.twothousand, a.twothousand)
|
|
|
|
from tenk1 a left join tenk1 b on b.thousand = a.unique1 left join tenk1 c on c.unique2 = coalesce(b.twothousand, a.twothousand)
|
|
|
|
where a.unique2 = 5530 and coalesce(b.twothousand, a.twothousand) = 44;
|
|
|
|
|
|
|
|
select a.unique1, b.unique1, c.unique1, coalesce(b.twothousand, a.twothousand)
|
|
|
|
from tenk1 a left join tenk1 b on b.thousand = a.unique1 left join tenk1 c on c.unique2 = coalesce(b.twothousand, a.twothousand)
|
|
|
|
where a.unique2 = 5530 and coalesce(b.twothousand, a.twothousand) = 44;
|
|
|
|
|
Flatten join alias Vars before pulling up targetlist items from a subquery.
pullup_replace_vars()'s decisions about whether a pulled-up replacement
expression needs to be wrapped in a PlaceHolderVar depend on the assumption
that what looks like a Var behaves like a Var. However, if the Var is a
join alias reference, later flattening of join aliases might replace the
Var with something that's not a Var at all, and should have been wrapped.
To fix, do a forcible pass of flatten_join_alias_vars() on the subquery
targetlist before we start to copy items out of it. We'll re-run that
processing on the pulled-up expressions later, but that's harmless.
Per report from Ken Tanzer; the added regression test case is based on his
example. This bug has been there since the PlaceHolderVar mechanism was
invented, but has escaped detection because the circumstances that trigger
it are fairly narrow. You need a flattenable query underneath an outer
join, which contains another flattenable query inside a join of its own,
with a dangerous expression (a constant or something else non-strict)
in that one's targetlist.
Having seen this, I'm wondering if it wouldn't be prudent to do all
alias-variable flattening earlier, perhaps even in the rewriter.
But that would probably not be a back-patchable change.
2013-11-22 20:37:21 +01:00
|
|
|
--
|
|
|
|
-- check handling of join aliases when flattening multiple levels of subquery
|
|
|
|
--
|
|
|
|
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select foo1.join_key as foo1_id, foo3.join_key AS foo3_id, bug_field from
|
|
|
|
(values (0),(1)) foo1(join_key)
|
|
|
|
left join
|
|
|
|
(select join_key, bug_field from
|
|
|
|
(select ss1.join_key, ss1.bug_field from
|
|
|
|
(select f1 as join_key, 666 as bug_field from int4_tbl i1) ss1
|
|
|
|
) foo2
|
|
|
|
left join
|
|
|
|
(select unique2 as join_key from tenk1 i2) ss2
|
|
|
|
using (join_key)
|
|
|
|
) foo3
|
|
|
|
using (join_key);
|
|
|
|
|
|
|
|
select foo1.join_key as foo1_id, foo3.join_key AS foo3_id, bug_field from
|
|
|
|
(values (0),(1)) foo1(join_key)
|
|
|
|
left join
|
|
|
|
(select join_key, bug_field from
|
|
|
|
(select ss1.join_key, ss1.bug_field from
|
|
|
|
(select f1 as join_key, 666 as bug_field from int4_tbl i1) ss1
|
|
|
|
) foo2
|
|
|
|
left join
|
|
|
|
(select unique2 as join_key from tenk1 i2) ss2
|
|
|
|
using (join_key)
|
|
|
|
) foo3
|
|
|
|
using (join_key);
|
|
|
|
|
Fix planning of non-strict equivalence clauses above outer joins.
If a potential equivalence clause references a variable from the nullable
side of an outer join, the planner needs to take care that derived clauses
are not pushed to below the outer join; else they may use the wrong value
for the variable. (The problem arises only with non-strict clauses, since
if an upper clause can be proven strict then the outer join will get
simplified to a plain join.) The planner attempted to prevent this type
of error by checking that potential equivalence clauses aren't
outerjoin-delayed as a whole, but actually we have to check each side
separately, since the two sides of the clause will get moved around
separately if it's treated as an equivalence. Bugs of this type can be
demonstrated as far back as 7.4, even though releases before 8.3 had only
a very ad-hoc notion of equivalence clauses.
In addition, we neglected to account for the possibility that such clauses
might have nonempty nullable_relids even when not outerjoin-delayed; so the
equivalence-class machinery lacked logic to compute correct nullable_relids
values for clauses it constructs. This oversight was harmless before 9.2
because we were only using RestrictInfo.nullable_relids for OR clauses;
but as of 9.2 it could result in pushing constructed equivalence clauses
to incorrect places. (This accounts for bug #7604 from Bill MacArthur.)
Fix the first problem by adding a new test check_equivalence_delay() in
distribute_qual_to_rels, and fix the second one by adding code in
equivclass.c and called functions to set correct nullable_relids for
generated clauses. Although I believe the second part of this is not
currently necessary before 9.2, I chose to back-patch it anyway, partly to
keep the logic similar across branches and partly because it seems possible
we might find other reasons why we need valid values of nullable_relids in
the older branches.
Add regression tests illustrating these problems. In 9.0 and up, also
add test cases checking that we can push constants through outer joins,
since we've broken that optimization before and I nearly broke it again
with an overly simplistic patch for this problem.
2012-10-18 18:28:45 +02:00
|
|
|
--
|
|
|
|
-- test ability to push constants through outer join clauses
|
|
|
|
--
|
|
|
|
|
|
|
|
explain (costs off)
|
|
|
|
select * from int4_tbl a left join tenk1 b on f1 = unique2 where f1 = 0;
|
|
|
|
|
|
|
|
explain (costs off)
|
|
|
|
select * from tenk1 a full join tenk1 b using(unique2) where unique2 = 42;
|
|
|
|
|
2010-03-22 14:57:16 +01:00
|
|
|
--
|
|
|
|
-- test join removal
|
|
|
|
--
|
|
|
|
|
2010-03-29 00:59:34 +02:00
|
|
|
begin;
|
|
|
|
|
|
|
|
CREATE TEMP TABLE a (id int PRIMARY KEY, b_id int);
|
|
|
|
CREATE TEMP TABLE b (id int PRIMARY KEY, c_id int);
|
|
|
|
CREATE TEMP TABLE c (id int PRIMARY KEY);
|
|
|
|
INSERT INTO a VALUES (0, 0), (1, NULL);
|
|
|
|
INSERT INTO b VALUES (0, 0), (1, NULL);
|
|
|
|
INSERT INTO c VALUES (0), (1);
|
|
|
|
|
|
|
|
-- all three cases should be optimizable into a simple seqscan
|
|
|
|
explain (costs off) SELECT a.* FROM a LEFT JOIN b ON a.b_id = b.id;
|
|
|
|
explain (costs off) SELECT b.* FROM b LEFT JOIN c ON b.c_id = c.id;
|
|
|
|
explain (costs off)
|
|
|
|
SELECT a.* FROM a LEFT JOIN (b left join c on b.c_id = c.id)
|
|
|
|
ON (a.b_id = b.id);
|
|
|
|
|
2010-05-23 18:34:38 +02:00
|
|
|
-- check optimization of outer join within another special join
|
|
|
|
explain (costs off)
|
|
|
|
select id from a where id in (
|
|
|
|
select b.id from b left join c on b.id = c.id
|
|
|
|
);
|
|
|
|
|
2010-03-29 00:59:34 +02:00
|
|
|
rollback;
|
|
|
|
|
2010-03-22 14:57:16 +01:00
|
|
|
create temp table parent (k int primary key, pd int);
|
|
|
|
create temp table child (k int unique, cd int);
|
|
|
|
insert into parent values (1, 10), (2, 20), (3, 30);
|
|
|
|
insert into child values (1, 100), (4, 400);
|
|
|
|
|
|
|
|
-- this case is optimizable
|
|
|
|
select p.* from parent p left join child c on (p.k = c.k);
|
|
|
|
explain (costs off)
|
|
|
|
select p.* from parent p left join child c on (p.k = c.k);
|
|
|
|
|
|
|
|
-- this case is not
|
|
|
|
select p.*, linked from parent p
|
|
|
|
left join (select c.*, true as linked from child c) as ss
|
|
|
|
on (p.k = ss.k);
|
|
|
|
explain (costs off)
|
|
|
|
select p.*, linked from parent p
|
|
|
|
left join (select c.*, true as linked from child c) as ss
|
|
|
|
on (p.k = ss.k);
|
2010-03-29 00:59:34 +02:00
|
|
|
|
2010-09-15 01:15:29 +02:00
|
|
|
-- check for a 9.0rc1 bug: join removal breaks pseudoconstant qual handling
|
|
|
|
select p.* from
|
|
|
|
parent p left join child c on (p.k = c.k)
|
|
|
|
where p.k = 1 and p.k = 2;
|
|
|
|
explain (costs off)
|
|
|
|
select p.* from
|
|
|
|
parent p left join child c on (p.k = c.k)
|
|
|
|
where p.k = 1 and p.k = 2;
|
|
|
|
|
|
|
|
select p.* from
|
|
|
|
(parent p left join child c on (p.k = c.k)) join parent x on p.k = x.k
|
|
|
|
where p.k = 1 and p.k = 2;
|
|
|
|
explain (costs off)
|
|
|
|
select p.* from
|
|
|
|
(parent p left join child c on (p.k = c.k)) join parent x on p.k = x.k
|
|
|
|
where p.k = 1 and p.k = 2;
|
|
|
|
|
2010-03-29 00:59:34 +02:00
|
|
|
-- bug 5255: this is not optimizable by join removal
|
|
|
|
begin;
|
|
|
|
|
|
|
|
CREATE TEMP TABLE a (id int PRIMARY KEY);
|
|
|
|
CREATE TEMP TABLE b (id int PRIMARY KEY, a_id int);
|
|
|
|
INSERT INTO a VALUES (0), (1);
|
|
|
|
INSERT INTO b VALUES (0, 0), (1, NULL);
|
|
|
|
|
|
|
|
SELECT * FROM b LEFT JOIN a ON (b.a_id = a.id) WHERE (a.id IS NULL OR a.id > 0);
|
|
|
|
SELECT b.* FROM b LEFT JOIN a ON (b.a_id = a.id) WHERE (a.id IS NULL OR a.id > 0);
|
|
|
|
|
|
|
|
rollback;
|
2010-09-26 01:03:50 +02:00
|
|
|
|
|
|
|
-- another join removal bug: this is not optimizable, either
|
|
|
|
begin;
|
|
|
|
|
|
|
|
create temp table innertab (id int8 primary key, dat1 int8);
|
|
|
|
insert into innertab values(123, 42);
|
|
|
|
|
|
|
|
SELECT * FROM
|
|
|
|
(SELECT 1 AS x) ss1
|
|
|
|
LEFT JOIN
|
|
|
|
(SELECT q1, q2, COALESCE(dat1, q1) AS y
|
|
|
|
FROM int8_tbl LEFT JOIN innertab ON q2 = id) ss2
|
|
|
|
ON true;
|
|
|
|
|
|
|
|
rollback;
|
2012-08-08 01:02:54 +02:00
|
|
|
|
2013-11-11 16:42:57 +01:00
|
|
|
-- bug #8444: we've historically allowed duplicate aliases within aliased JOINs
|
|
|
|
|
|
|
|
select * from
|
|
|
|
int8_tbl x join (int4_tbl x cross join int4_tbl y) j on q1 = f1; -- error
|
|
|
|
select * from
|
|
|
|
int8_tbl x join (int4_tbl x cross join int4_tbl y) j on q1 = y.f1; -- error
|
|
|
|
select * from
|
|
|
|
int8_tbl x join (int4_tbl x cross join int4_tbl y(ff)) j on q1 = f1; -- ok
|
|
|
|
|
2012-08-08 01:02:54 +02:00
|
|
|
--
|
|
|
|
-- Test LATERAL
|
|
|
|
--
|
|
|
|
|
|
|
|
select unique2, x.*
|
|
|
|
from tenk1 a, lateral (select * from int4_tbl b where f1 = a.unique1) x;
|
|
|
|
explain (costs off)
|
|
|
|
select unique2, x.*
|
|
|
|
from tenk1 a, lateral (select * from int4_tbl b where f1 = a.unique1) x;
|
|
|
|
select unique2, x.*
|
|
|
|
from int4_tbl x, lateral (select unique2 from tenk1 where f1 = unique1) ss;
|
|
|
|
explain (costs off)
|
|
|
|
select unique2, x.*
|
|
|
|
from int4_tbl x, lateral (select unique2 from tenk1 where f1 = unique1) ss;
|
|
|
|
explain (costs off)
|
|
|
|
select unique2, x.*
|
|
|
|
from int4_tbl x cross join lateral (select unique2 from tenk1 where f1 = unique1) ss;
|
|
|
|
select unique2, x.*
|
2012-09-16 23:57:18 +02:00
|
|
|
from int4_tbl x left join lateral (select unique1, unique2 from tenk1 where f1 = unique1) ss on true;
|
2012-08-08 01:02:54 +02:00
|
|
|
explain (costs off)
|
|
|
|
select unique2, x.*
|
2012-09-16 23:57:18 +02:00
|
|
|
from int4_tbl x left join lateral (select unique1, unique2 from tenk1 where f1 = unique1) ss on true;
|
2012-08-08 01:02:54 +02:00
|
|
|
|
|
|
|
-- check scoping of lateral versus parent references
|
|
|
|
-- the first of these should return int8_tbl.q2, the second int8_tbl.q1
|
|
|
|
select *, (select r from (select q1 as q2) x, (select q2 as r) y) from int8_tbl;
|
|
|
|
select *, (select r from (select q1 as q2) x, lateral (select q2 as r) y) from int8_tbl;
|
|
|
|
|
2013-01-26 22:18:42 +01:00
|
|
|
-- lateral with function in FROM
|
2012-08-08 01:02:54 +02:00
|
|
|
select count(*) from tenk1 a, lateral generate_series(1,two) g;
|
|
|
|
explain (costs off)
|
|
|
|
select count(*) from tenk1 a, lateral generate_series(1,two) g;
|
|
|
|
explain (costs off)
|
|
|
|
select count(*) from tenk1 a cross join lateral generate_series(1,two) g;
|
2013-01-26 22:18:42 +01:00
|
|
|
-- don't need the explicit LATERAL keyword for functions
|
|
|
|
explain (costs off)
|
|
|
|
select count(*) from tenk1 a, generate_series(1,two) g;
|
2012-08-08 01:02:54 +02:00
|
|
|
|
2012-08-12 00:42:20 +02:00
|
|
|
-- lateral with UNION ALL subselect
|
|
|
|
explain (costs off)
|
|
|
|
select * from generate_series(100,200) g,
|
|
|
|
lateral (select * from int8_tbl a where g = q1 union all
|
|
|
|
select * from int8_tbl b where g = q2) ss;
|
|
|
|
select * from generate_series(100,200) g,
|
|
|
|
lateral (select * from int8_tbl a where g = q1 union all
|
|
|
|
select * from int8_tbl b where g = q2) ss;
|
|
|
|
|
2012-08-12 22:01:26 +02:00
|
|
|
-- lateral with VALUES
|
|
|
|
explain (costs off)
|
|
|
|
select count(*) from tenk1 a,
|
|
|
|
tenk1 b join lateral (values(a.unique1)) ss(x) on b.unique2 = ss.x;
|
|
|
|
select count(*) from tenk1 a,
|
|
|
|
tenk1 b join lateral (values(a.unique1)) ss(x) on b.unique2 = ss.x;
|
|
|
|
|
|
|
|
-- lateral injecting a strange outer join condition
|
|
|
|
explain (costs off)
|
|
|
|
select * from int8_tbl a,
|
|
|
|
int8_tbl x left join lateral (select a.q1 from int4_tbl y) ss(z)
|
|
|
|
on x.q2 = ss.z;
|
|
|
|
select * from int8_tbl a,
|
|
|
|
int8_tbl x left join lateral (select a.q1 from int4_tbl y) ss(z)
|
|
|
|
on x.q2 = ss.z;
|
|
|
|
|
2012-08-31 23:44:01 +02:00
|
|
|
-- lateral reference to a join alias variable
|
|
|
|
select * from (select f1/2 as x from int4_tbl) ss1 join int4_tbl i4 on x = f1,
|
|
|
|
lateral (select x) ss2(y);
|
|
|
|
select * from (select f1 as x from int4_tbl) ss1 join int4_tbl i4 on x = f1,
|
|
|
|
lateral (values(x)) ss2(y);
|
|
|
|
select * from ((select f1/2 as x from int4_tbl) ss1 join int4_tbl i4 on x = f1) j,
|
|
|
|
lateral (select x) ss2(y);
|
|
|
|
|
2012-08-18 20:10:17 +02:00
|
|
|
-- lateral references requiring pullup
|
|
|
|
select * from (values(1)) x(lb),
|
|
|
|
lateral generate_series(lb,4) x4;
|
|
|
|
select * from (select f1/1000000000 from int4_tbl) x(lb),
|
|
|
|
lateral generate_series(lb,4) x4;
|
|
|
|
select * from (values(1)) x(lb),
|
|
|
|
lateral (values(lb)) y(lbcopy);
|
|
|
|
select * from (values(1)) x(lb),
|
|
|
|
lateral (select lb from int4_tbl) y(lbcopy);
|
|
|
|
select * from
|
|
|
|
int8_tbl x left join (select q1,coalesce(q2,0) q2 from int8_tbl) y on x.q2 = y.q1,
|
|
|
|
lateral (values(x.q1,y.q1,y.q2)) v(xq1,yq1,yq2);
|
|
|
|
select * from
|
|
|
|
int8_tbl x left join (select q1,coalesce(q2,0) q2 from int8_tbl) y on x.q2 = y.q1,
|
|
|
|
lateral (select x.q1,y.q1,y.q2) v(xq1,yq1,yq2);
|
2012-08-27 04:48:55 +02:00
|
|
|
select x.* from
|
|
|
|
int8_tbl x left join (select q1,coalesce(q2,0) q2 from int8_tbl) y on x.q2 = y.q1,
|
|
|
|
lateral (select x.q1,y.q1,y.q2) v(xq1,yq1,yq2);
|
|
|
|
select v.* from
|
|
|
|
(int8_tbl x left join (select q1,coalesce(q2,0) q2 from int8_tbl) y on x.q2 = y.q1)
|
|
|
|
left join int4_tbl z on z.f1 = x.q2,
|
|
|
|
lateral (select x.q1,y.q1 union all select x.q2,y.q2) v(vx,vy);
|
|
|
|
select v.* from
|
|
|
|
(int8_tbl x left join (select q1,(select coalesce(q2,0)) q2 from int8_tbl) y on x.q2 = y.q1)
|
|
|
|
left join int4_tbl z on z.f1 = x.q2,
|
|
|
|
lateral (select x.q1,y.q1 union all select x.q2,y.q2) v(vx,vy);
|
|
|
|
create temp table dual();
|
|
|
|
insert into dual default values;
|
2012-09-02 00:16:24 +02:00
|
|
|
analyze dual;
|
2012-08-27 04:48:55 +02:00
|
|
|
select v.* from
|
|
|
|
(int8_tbl x left join (select q1,(select coalesce(q2,0)) q2 from int8_tbl) y on x.q2 = y.q1)
|
|
|
|
left join int4_tbl z on z.f1 = x.q2,
|
|
|
|
lateral (select x.q1,y.q1 from dual union all select x.q2,y.q2 from dual) v(vx,vy);
|
2012-08-18 20:10:17 +02:00
|
|
|
|
2013-08-18 02:22:37 +02:00
|
|
|
explain (verbose, costs off)
|
|
|
|
select * from
|
|
|
|
int8_tbl a left join
|
|
|
|
lateral (select *, a.q2 as x from int8_tbl b) ss on a.q2 = ss.q1;
|
|
|
|
select * from
|
|
|
|
int8_tbl a left join
|
|
|
|
lateral (select *, a.q2 as x from int8_tbl b) ss on a.q2 = ss.q1;
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select * from
|
|
|
|
int8_tbl a left join
|
|
|
|
lateral (select *, coalesce(a.q2, 42) as x from int8_tbl b) ss on a.q2 = ss.q1;
|
|
|
|
select * from
|
|
|
|
int8_tbl a left join
|
|
|
|
lateral (select *, coalesce(a.q2, 42) as x from int8_tbl b) ss on a.q2 = ss.q1;
|
|
|
|
|
|
|
|
-- lateral can result in join conditions appearing below their
|
|
|
|
-- real semantic level
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select * from int4_tbl i left join
|
|
|
|
lateral (select * from int2_tbl j where i.f1 = j.f1) k on true;
|
|
|
|
select * from int4_tbl i left join
|
|
|
|
lateral (select * from int2_tbl j where i.f1 = j.f1) k on true;
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select * from int4_tbl i left join
|
|
|
|
lateral (select coalesce(i) from int2_tbl j where i.f1 = j.f1) k on true;
|
|
|
|
select * from int4_tbl i left join
|
|
|
|
lateral (select coalesce(i) from int2_tbl j where i.f1 = j.f1) k on true;
|
2013-08-19 19:19:25 +02:00
|
|
|
explain (verbose, costs off)
|
|
|
|
select * from int4_tbl a,
|
|
|
|
lateral (
|
|
|
|
select * from int4_tbl b left join int8_tbl c on (b.f1 = q1 and a.f1 = q2)
|
|
|
|
) ss;
|
|
|
|
select * from int4_tbl a,
|
|
|
|
lateral (
|
|
|
|
select * from int4_tbl b left join int8_tbl c on (b.f1 = q1 and a.f1 = q2)
|
|
|
|
) ss;
|
2013-08-18 02:22:37 +02:00
|
|
|
|
|
|
|
-- lateral reference in a PlaceHolderVar evaluated at join level
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select * from
|
|
|
|
int8_tbl a left join lateral
|
|
|
|
(select b.q1 as bq1, c.q1 as cq1, least(a.q1,b.q1,c.q1) from
|
|
|
|
int8_tbl b cross join int8_tbl c) ss
|
|
|
|
on a.q2 = ss.bq1;
|
|
|
|
select * from
|
|
|
|
int8_tbl a left join lateral
|
|
|
|
(select b.q1 as bq1, c.q1 as cq1, least(a.q1,b.q1,c.q1) from
|
|
|
|
int8_tbl b cross join int8_tbl c) ss
|
|
|
|
on a.q2 = ss.bq1;
|
|
|
|
|
2012-09-01 19:56:14 +02:00
|
|
|
-- case requiring nested PlaceHolderVars
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select * from
|
|
|
|
int8_tbl c left join (
|
|
|
|
int8_tbl a left join (select q1, coalesce(q2,42) as x from int8_tbl b) ss1
|
|
|
|
on a.q2 = ss1.q1
|
|
|
|
cross join
|
|
|
|
lateral (select q1, coalesce(ss1.x,q2) as y from int8_tbl d) ss2
|
|
|
|
) on c.q2 = ss2.q1,
|
|
|
|
lateral (select ss2.y) ss3;
|
|
|
|
|
2013-08-15 00:38:32 +02:00
|
|
|
-- case that breaks the old ph_may_need optimization
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select c.*,a.*,ss1.q1,ss2.q1,ss3.* from
|
|
|
|
int8_tbl c left join (
|
|
|
|
int8_tbl a left join
|
|
|
|
(select q1, coalesce(q2,f1) as x from int8_tbl b, int4_tbl b2
|
|
|
|
where q1 < f1) ss1
|
|
|
|
on a.q2 = ss1.q1
|
|
|
|
cross join
|
|
|
|
lateral (select q1, coalesce(ss1.x,q2) as y from int8_tbl d) ss2
|
|
|
|
) on c.q2 = ss2.q1,
|
|
|
|
lateral (select * from int4_tbl i where ss2.y > f1) ss3;
|
|
|
|
|
2014-01-30 20:51:16 +01:00
|
|
|
-- check processing of postponed quals (bug #9041)
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select * from
|
|
|
|
(select 1 as x) x cross join (select 2 as y) y
|
|
|
|
left join lateral (
|
|
|
|
select * from (select 3 as z) z where z.z = x.x
|
|
|
|
) zz on zz.z = y.y;
|
|
|
|
|
2012-08-08 01:02:54 +02:00
|
|
|
-- test some error cases where LATERAL should have been used but wasn't
|
2013-01-26 22:18:42 +01:00
|
|
|
select f1,g from int4_tbl a, (select f1 as g) ss;
|
|
|
|
select f1,g from int4_tbl a, (select a.f1 as g) ss;
|
|
|
|
select f1,g from int4_tbl a cross join (select f1 as g) ss;
|
|
|
|
select f1,g from int4_tbl a cross join (select a.f1 as g) ss;
|
2012-08-08 01:02:54 +02:00
|
|
|
-- SQL:2008 says the left table is in scope but illegal to access here
|
|
|
|
select f1,g from int4_tbl a right join lateral generate_series(0, a.f1) g on true;
|
|
|
|
select f1,g from int4_tbl a full join lateral generate_series(0, a.f1) g on true;
|
2013-11-11 16:42:57 +01:00
|
|
|
-- check we complain about ambiguous table references
|
|
|
|
select * from
|
|
|
|
int8_tbl x cross join (int4_tbl x cross join lateral (select x.f1) ss);
|
2012-08-08 01:02:54 +02:00
|
|
|
-- LATERAL can be used to put an aggregate into the FROM clause of its query
|
|
|
|
select 1 from tenk1 a, lateral (select max(a.unique1) from int4_tbl b) ss;
|
2014-01-07 21:25:16 +01:00
|
|
|
|
|
|
|
-- check behavior of LATERAL in UPDATE/DELETE
|
|
|
|
|
|
|
|
create temp table xx1 as select f1 as x1, -f1 as x2 from int4_tbl;
|
|
|
|
|
2014-01-12 01:03:12 +01:00
|
|
|
-- error, can't do this:
|
2014-01-07 21:25:16 +01:00
|
|
|
update xx1 set x2 = f1 from (select * from int4_tbl where f1 = x1) ss;
|
|
|
|
update xx1 set x2 = f1 from (select * from int4_tbl where f1 = xx1.x1) ss;
|
2014-01-12 01:03:12 +01:00
|
|
|
-- can't do it even with LATERAL:
|
2014-01-07 21:25:16 +01:00
|
|
|
update xx1 set x2 = f1 from lateral (select * from int4_tbl where f1 = x1) ss;
|
2014-01-12 01:03:12 +01:00
|
|
|
-- we might in future allow something like this, but for now it's an error:
|
|
|
|
update xx1 set x2 = f1 from xx1, lateral (select * from int4_tbl where f1 = x1) ss;
|
2014-01-07 21:25:16 +01:00
|
|
|
|
2014-01-12 01:03:12 +01:00
|
|
|
-- also errors:
|
2014-01-07 21:25:16 +01:00
|
|
|
delete from xx1 using (select * from int4_tbl where f1 = x1) ss;
|
2014-01-12 01:03:12 +01:00
|
|
|
delete from xx1 using (select * from int4_tbl where f1 = xx1.x1) ss;
|
2014-01-07 21:25:16 +01:00
|
|
|
delete from xx1 using lateral (select * from int4_tbl where f1 = x1) ss;
|