Fix some more problems with nested append relations.
As of commit a87c72915 (which later got backpatched as far as 9.1),
we're explicitly supporting the notion that append relations can be
nested; this can occur when UNION ALL constructs are nested, or when
a UNION ALL contains a table with inheritance children.
Bug #11457 from Nelson Page, as well as an earlier report from Elvis
Pranskevichus, showed that there were still nasty bugs associated with such
cases: in particular the EquivalenceClass mechanism could try to generate
"join" clauses connecting an appendrel child to some grandparent appendrel,
which would result in assertion failures or bogus plans.
Upon investigation I concluded that all current callers of
find_childrel_appendrelinfo() need to be fixed to explicitly consider
multiple levels of parent appendrels. The most complex fix was in
processing of "broken" EquivalenceClasses, which are ECs for which we have
been unable to generate all the derived equality clauses we would like to
because of missing cross-type equality operators in the underlying btree
operator family. That code path is more or less entirely untested by
the regression tests to date, because no standard opfamilies have such
holes in them. So I wrote a new regression test script to try to exercise
it a bit, which turned out to be quite a worthwhile activity as it exposed
existing bugs in all supported branches.
The present patch is essentially the same as far back as 9.2, which is
where parameterized paths were introduced. In 9.0 and 9.1, we only need
to back-patch a small fragment of commit 5b7b5518d, which fixes failure to
propagate out the original WHERE clauses when a broken EC contains constant
members. (The regression test case results show that these older branches
are noticeably stupider than 9.2+ in terms of the quality of the plans
generated; but we don't really care about plan quality in such cases,
only that the plan not be outright wrong. A more invasive fix in the
older branches would not be a good idea anyway from a plan-stability
standpoint.)
2014-10-02 01:30:24 +02:00
|
|
|
--
|
|
|
|
-- Tests for the planner's "equivalence class" mechanism
|
|
|
|
--
|
|
|
|
-- One thing that's not tested well during normal querying is the logic
|
|
|
|
-- for handling "broken" ECs. This is because an EC can only become broken
|
|
|
|
-- if its underlying btree operator family doesn't include a complete set
|
|
|
|
-- of cross-type equality operators. There are not (and should not be)
|
|
|
|
-- any such families built into Postgres; so we have to hack things up
|
|
|
|
-- to create one. We do this by making two alias types that are really
|
|
|
|
-- int8 (so we need no new C code) and adding only some operators for them
|
|
|
|
-- into the standard integer_ops opfamily.
|
|
|
|
create type int8alias1;
|
|
|
|
create function int8alias1in(cstring) returns int8alias1
|
|
|
|
strict immutable language internal as 'int8in';
|
|
|
|
NOTICE: return type int8alias1 is only a shell
|
|
|
|
create function int8alias1out(int8alias1) returns cstring
|
|
|
|
strict immutable language internal as 'int8out';
|
|
|
|
NOTICE: argument type int8alias1 is only a shell
|
|
|
|
create type int8alias1 (
|
|
|
|
input = int8alias1in,
|
|
|
|
output = int8alias1out,
|
|
|
|
like = int8
|
|
|
|
);
|
|
|
|
create type int8alias2;
|
|
|
|
create function int8alias2in(cstring) returns int8alias2
|
|
|
|
strict immutable language internal as 'int8in';
|
|
|
|
NOTICE: return type int8alias2 is only a shell
|
|
|
|
create function int8alias2out(int8alias2) returns cstring
|
|
|
|
strict immutable language internal as 'int8out';
|
|
|
|
NOTICE: argument type int8alias2 is only a shell
|
|
|
|
create type int8alias2 (
|
|
|
|
input = int8alias2in,
|
|
|
|
output = int8alias2out,
|
|
|
|
like = int8
|
|
|
|
);
|
|
|
|
create cast (int8 as int8alias1) without function;
|
|
|
|
create cast (int8 as int8alias2) without function;
|
|
|
|
create cast (int8alias1 as int8) without function;
|
|
|
|
create cast (int8alias2 as int8) without function;
|
|
|
|
create function int8alias1eq(int8alias1, int8alias1) returns bool
|
|
|
|
strict immutable language internal as 'int8eq';
|
|
|
|
create operator = (
|
|
|
|
procedure = int8alias1eq,
|
|
|
|
leftarg = int8alias1, rightarg = int8alias1,
|
|
|
|
commutator = =,
|
|
|
|
restrict = eqsel, join = eqjoinsel,
|
|
|
|
merges
|
|
|
|
);
|
|
|
|
alter operator family integer_ops using btree add
|
|
|
|
operator 3 = (int8alias1, int8alias1);
|
|
|
|
create function int8alias2eq(int8alias2, int8alias2) returns bool
|
|
|
|
strict immutable language internal as 'int8eq';
|
|
|
|
create operator = (
|
|
|
|
procedure = int8alias2eq,
|
|
|
|
leftarg = int8alias2, rightarg = int8alias2,
|
|
|
|
commutator = =,
|
|
|
|
restrict = eqsel, join = eqjoinsel,
|
|
|
|
merges
|
|
|
|
);
|
|
|
|
alter operator family integer_ops using btree add
|
|
|
|
operator 3 = (int8alias2, int8alias2);
|
|
|
|
create function int8alias1eq(int8, int8alias1) returns bool
|
|
|
|
strict immutable language internal as 'int8eq';
|
|
|
|
create operator = (
|
|
|
|
procedure = int8alias1eq,
|
|
|
|
leftarg = int8, rightarg = int8alias1,
|
|
|
|
restrict = eqsel, join = eqjoinsel,
|
|
|
|
merges
|
|
|
|
);
|
|
|
|
alter operator family integer_ops using btree add
|
|
|
|
operator 3 = (int8, int8alias1);
|
|
|
|
create function int8alias1eq(int8alias1, int8alias2) returns bool
|
|
|
|
strict immutable language internal as 'int8eq';
|
|
|
|
create operator = (
|
|
|
|
procedure = int8alias1eq,
|
|
|
|
leftarg = int8alias1, rightarg = int8alias2,
|
|
|
|
restrict = eqsel, join = eqjoinsel,
|
|
|
|
merges
|
|
|
|
);
|
|
|
|
alter operator family integer_ops using btree add
|
|
|
|
operator 3 = (int8alias1, int8alias2);
|
|
|
|
create function int8alias1lt(int8alias1, int8alias1) returns bool
|
|
|
|
strict immutable language internal as 'int8lt';
|
|
|
|
create operator < (
|
|
|
|
procedure = int8alias1lt,
|
|
|
|
leftarg = int8alias1, rightarg = int8alias1
|
|
|
|
);
|
|
|
|
alter operator family integer_ops using btree add
|
|
|
|
operator 1 < (int8alias1, int8alias1);
|
|
|
|
create function int8alias1cmp(int8, int8alias1) returns int
|
|
|
|
strict immutable language internal as 'btint8cmp';
|
|
|
|
alter operator family integer_ops using btree add
|
|
|
|
function 1 int8alias1cmp (int8, int8alias1);
|
|
|
|
create table ec0 (ff int8 primary key, f1 int8, f2 int8);
|
|
|
|
create table ec1 (ff int8 primary key, f1 int8alias1, f2 int8alias2);
|
|
|
|
create table ec2 (xf int8 primary key, x1 int8alias1, x2 int8alias2);
|
|
|
|
-- for the moment we only want to look at nestloop plans
|
|
|
|
set enable_hashjoin = off;
|
|
|
|
set enable_mergejoin = off;
|
|
|
|
--
|
|
|
|
-- Note that for cases where there's a missing operator, we don't care so
|
|
|
|
-- much whether the plan is ideal as that we don't fail or generate an
|
|
|
|
-- outright incorrect plan.
|
|
|
|
--
|
|
|
|
explain (costs off)
|
|
|
|
select * from ec0 where ff = f1 and f1 = '42'::int8;
|
2015-03-30 20:59:49 +02:00
|
|
|
QUERY PLAN
|
|
|
|
-----------------------------------
|
Fix some more problems with nested append relations.
As of commit a87c72915 (which later got backpatched as far as 9.1),
we're explicitly supporting the notion that append relations can be
nested; this can occur when UNION ALL constructs are nested, or when
a UNION ALL contains a table with inheritance children.
Bug #11457 from Nelson Page, as well as an earlier report from Elvis
Pranskevichus, showed that there were still nasty bugs associated with such
cases: in particular the EquivalenceClass mechanism could try to generate
"join" clauses connecting an appendrel child to some grandparent appendrel,
which would result in assertion failures or bogus plans.
Upon investigation I concluded that all current callers of
find_childrel_appendrelinfo() need to be fixed to explicitly consider
multiple levels of parent appendrels. The most complex fix was in
processing of "broken" EquivalenceClasses, which are ECs for which we have
been unable to generate all the derived equality clauses we would like to
because of missing cross-type equality operators in the underlying btree
operator family. That code path is more or less entirely untested by
the regression tests to date, because no standard opfamilies have such
holes in them. So I wrote a new regression test script to try to exercise
it a bit, which turned out to be quite a worthwhile activity as it exposed
existing bugs in all supported branches.
The present patch is essentially the same as far back as 9.2, which is
where parameterized paths were introduced. In 9.0 and 9.1, we only need
to back-patch a small fragment of commit 5b7b5518d, which fixes failure to
propagate out the original WHERE clauses when a broken EC contains constant
members. (The regression test case results show that these older branches
are noticeably stupider than 9.2+ in terms of the quality of the plans
generated; but we don't really care about plan quality in such cases,
only that the plan not be outright wrong. A more invasive fix in the
older branches would not be a good idea anyway from a plan-stability
standpoint.)
2014-10-02 01:30:24 +02:00
|
|
|
Index Scan using ec0_pkey on ec0
|
2015-03-30 20:59:49 +02:00
|
|
|
Index Cond: (ff = '42'::bigint)
|
|
|
|
Filter: (f1 = '42'::bigint)
|
Fix some more problems with nested append relations.
As of commit a87c72915 (which later got backpatched as far as 9.1),
we're explicitly supporting the notion that append relations can be
nested; this can occur when UNION ALL constructs are nested, or when
a UNION ALL contains a table with inheritance children.
Bug #11457 from Nelson Page, as well as an earlier report from Elvis
Pranskevichus, showed that there were still nasty bugs associated with such
cases: in particular the EquivalenceClass mechanism could try to generate
"join" clauses connecting an appendrel child to some grandparent appendrel,
which would result in assertion failures or bogus plans.
Upon investigation I concluded that all current callers of
find_childrel_appendrelinfo() need to be fixed to explicitly consider
multiple levels of parent appendrels. The most complex fix was in
processing of "broken" EquivalenceClasses, which are ECs for which we have
been unable to generate all the derived equality clauses we would like to
because of missing cross-type equality operators in the underlying btree
operator family. That code path is more or less entirely untested by
the regression tests to date, because no standard opfamilies have such
holes in them. So I wrote a new regression test script to try to exercise
it a bit, which turned out to be quite a worthwhile activity as it exposed
existing bugs in all supported branches.
The present patch is essentially the same as far back as 9.2, which is
where parameterized paths were introduced. In 9.0 and 9.1, we only need
to back-patch a small fragment of commit 5b7b5518d, which fixes failure to
propagate out the original WHERE clauses when a broken EC contains constant
members. (The regression test case results show that these older branches
are noticeably stupider than 9.2+ in terms of the quality of the plans
generated; but we don't really care about plan quality in such cases,
only that the plan not be outright wrong. A more invasive fix in the
older branches would not be a good idea anyway from a plan-stability
standpoint.)
2014-10-02 01:30:24 +02:00
|
|
|
(3 rows)
|
|
|
|
|
|
|
|
explain (costs off)
|
|
|
|
select * from ec0 where ff = f1 and f1 = '42'::int8alias1;
|
|
|
|
QUERY PLAN
|
|
|
|
---------------------------------------
|
|
|
|
Index Scan using ec0_pkey on ec0
|
|
|
|
Index Cond: (ff = '42'::int8alias1)
|
|
|
|
Filter: (f1 = '42'::int8alias1)
|
|
|
|
(3 rows)
|
|
|
|
|
|
|
|
explain (costs off)
|
|
|
|
select * from ec1 where ff = f1 and f1 = '42'::int8alias1;
|
|
|
|
QUERY PLAN
|
|
|
|
---------------------------------------
|
|
|
|
Index Scan using ec1_pkey on ec1
|
|
|
|
Index Cond: (ff = '42'::int8alias1)
|
|
|
|
Filter: (f1 = '42'::int8alias1)
|
|
|
|
(3 rows)
|
|
|
|
|
|
|
|
explain (costs off)
|
|
|
|
select * from ec1 where ff = f1 and f1 = '42'::int8alias2;
|
|
|
|
QUERY PLAN
|
|
|
|
---------------------------------------------------
|
|
|
|
Seq Scan on ec1
|
|
|
|
Filter: ((ff = f1) AND (f1 = '42'::int8alias2))
|
|
|
|
(2 rows)
|
|
|
|
|
|
|
|
explain (costs off)
|
|
|
|
select * from ec1, ec2 where ff = x1 and ff = '42'::int8;
|
2015-03-30 20:59:49 +02:00
|
|
|
QUERY PLAN
|
|
|
|
-------------------------------------------------------------------
|
Fix some more problems with nested append relations.
As of commit a87c72915 (which later got backpatched as far as 9.1),
we're explicitly supporting the notion that append relations can be
nested; this can occur when UNION ALL constructs are nested, or when
a UNION ALL contains a table with inheritance children.
Bug #11457 from Nelson Page, as well as an earlier report from Elvis
Pranskevichus, showed that there were still nasty bugs associated with such
cases: in particular the EquivalenceClass mechanism could try to generate
"join" clauses connecting an appendrel child to some grandparent appendrel,
which would result in assertion failures or bogus plans.
Upon investigation I concluded that all current callers of
find_childrel_appendrelinfo() need to be fixed to explicitly consider
multiple levels of parent appendrels. The most complex fix was in
processing of "broken" EquivalenceClasses, which are ECs for which we have
been unable to generate all the derived equality clauses we would like to
because of missing cross-type equality operators in the underlying btree
operator family. That code path is more or less entirely untested by
the regression tests to date, because no standard opfamilies have such
holes in them. So I wrote a new regression test script to try to exercise
it a bit, which turned out to be quite a worthwhile activity as it exposed
existing bugs in all supported branches.
The present patch is essentially the same as far back as 9.2, which is
where parameterized paths were introduced. In 9.0 and 9.1, we only need
to back-patch a small fragment of commit 5b7b5518d, which fixes failure to
propagate out the original WHERE clauses when a broken EC contains constant
members. (The regression test case results show that these older branches
are noticeably stupider than 9.2+ in terms of the quality of the plans
generated; but we don't really care about plan quality in such cases,
only that the plan not be outright wrong. A more invasive fix in the
older branches would not be a good idea anyway from a plan-stability
standpoint.)
2014-10-02 01:30:24 +02:00
|
|
|
Nested Loop
|
|
|
|
Join Filter: (ec1.ff = ec2.x1)
|
|
|
|
-> Index Scan using ec1_pkey on ec1
|
2015-03-30 20:59:49 +02:00
|
|
|
Index Cond: ((ff = '42'::bigint) AND (ff = '42'::bigint))
|
Fix some more problems with nested append relations.
As of commit a87c72915 (which later got backpatched as far as 9.1),
we're explicitly supporting the notion that append relations can be
nested; this can occur when UNION ALL constructs are nested, or when
a UNION ALL contains a table with inheritance children.
Bug #11457 from Nelson Page, as well as an earlier report from Elvis
Pranskevichus, showed that there were still nasty bugs associated with such
cases: in particular the EquivalenceClass mechanism could try to generate
"join" clauses connecting an appendrel child to some grandparent appendrel,
which would result in assertion failures or bogus plans.
Upon investigation I concluded that all current callers of
find_childrel_appendrelinfo() need to be fixed to explicitly consider
multiple levels of parent appendrels. The most complex fix was in
processing of "broken" EquivalenceClasses, which are ECs for which we have
been unable to generate all the derived equality clauses we would like to
because of missing cross-type equality operators in the underlying btree
operator family. That code path is more or less entirely untested by
the regression tests to date, because no standard opfamilies have such
holes in them. So I wrote a new regression test script to try to exercise
it a bit, which turned out to be quite a worthwhile activity as it exposed
existing bugs in all supported branches.
The present patch is essentially the same as far back as 9.2, which is
where parameterized paths were introduced. In 9.0 and 9.1, we only need
to back-patch a small fragment of commit 5b7b5518d, which fixes failure to
propagate out the original WHERE clauses when a broken EC contains constant
members. (The regression test case results show that these older branches
are noticeably stupider than 9.2+ in terms of the quality of the plans
generated; but we don't really care about plan quality in such cases,
only that the plan not be outright wrong. A more invasive fix in the
older branches would not be a good idea anyway from a plan-stability
standpoint.)
2014-10-02 01:30:24 +02:00
|
|
|
-> Seq Scan on ec2
|
|
|
|
(5 rows)
|
|
|
|
|
|
|
|
explain (costs off)
|
|
|
|
select * from ec1, ec2 where ff = x1 and ff = '42'::int8alias1;
|
|
|
|
QUERY PLAN
|
|
|
|
---------------------------------------------
|
|
|
|
Nested Loop
|
|
|
|
-> Index Scan using ec1_pkey on ec1
|
|
|
|
Index Cond: (ff = '42'::int8alias1)
|
|
|
|
-> Seq Scan on ec2
|
|
|
|
Filter: (x1 = '42'::int8alias1)
|
|
|
|
(5 rows)
|
|
|
|
|
|
|
|
explain (costs off)
|
|
|
|
select * from ec1, ec2 where ff = x1 and '42'::int8 = x1;
|
2015-03-30 20:59:49 +02:00
|
|
|
QUERY PLAN
|
|
|
|
-----------------------------------------
|
Fix some more problems with nested append relations.
As of commit a87c72915 (which later got backpatched as far as 9.1),
we're explicitly supporting the notion that append relations can be
nested; this can occur when UNION ALL constructs are nested, or when
a UNION ALL contains a table with inheritance children.
Bug #11457 from Nelson Page, as well as an earlier report from Elvis
Pranskevichus, showed that there were still nasty bugs associated with such
cases: in particular the EquivalenceClass mechanism could try to generate
"join" clauses connecting an appendrel child to some grandparent appendrel,
which would result in assertion failures or bogus plans.
Upon investigation I concluded that all current callers of
find_childrel_appendrelinfo() need to be fixed to explicitly consider
multiple levels of parent appendrels. The most complex fix was in
processing of "broken" EquivalenceClasses, which are ECs for which we have
been unable to generate all the derived equality clauses we would like to
because of missing cross-type equality operators in the underlying btree
operator family. That code path is more or less entirely untested by
the regression tests to date, because no standard opfamilies have such
holes in them. So I wrote a new regression test script to try to exercise
it a bit, which turned out to be quite a worthwhile activity as it exposed
existing bugs in all supported branches.
The present patch is essentially the same as far back as 9.2, which is
where parameterized paths were introduced. In 9.0 and 9.1, we only need
to back-patch a small fragment of commit 5b7b5518d, which fixes failure to
propagate out the original WHERE clauses when a broken EC contains constant
members. (The regression test case results show that these older branches
are noticeably stupider than 9.2+ in terms of the quality of the plans
generated; but we don't really care about plan quality in such cases,
only that the plan not be outright wrong. A more invasive fix in the
older branches would not be a good idea anyway from a plan-stability
standpoint.)
2014-10-02 01:30:24 +02:00
|
|
|
Nested Loop
|
|
|
|
Join Filter: (ec1.ff = ec2.x1)
|
|
|
|
-> Index Scan using ec1_pkey on ec1
|
2015-03-30 20:59:49 +02:00
|
|
|
Index Cond: (ff = '42'::bigint)
|
Fix some more problems with nested append relations.
As of commit a87c72915 (which later got backpatched as far as 9.1),
we're explicitly supporting the notion that append relations can be
nested; this can occur when UNION ALL constructs are nested, or when
a UNION ALL contains a table with inheritance children.
Bug #11457 from Nelson Page, as well as an earlier report from Elvis
Pranskevichus, showed that there were still nasty bugs associated with such
cases: in particular the EquivalenceClass mechanism could try to generate
"join" clauses connecting an appendrel child to some grandparent appendrel,
which would result in assertion failures or bogus plans.
Upon investigation I concluded that all current callers of
find_childrel_appendrelinfo() need to be fixed to explicitly consider
multiple levels of parent appendrels. The most complex fix was in
processing of "broken" EquivalenceClasses, which are ECs for which we have
been unable to generate all the derived equality clauses we would like to
because of missing cross-type equality operators in the underlying btree
operator family. That code path is more or less entirely untested by
the regression tests to date, because no standard opfamilies have such
holes in them. So I wrote a new regression test script to try to exercise
it a bit, which turned out to be quite a worthwhile activity as it exposed
existing bugs in all supported branches.
The present patch is essentially the same as far back as 9.2, which is
where parameterized paths were introduced. In 9.0 and 9.1, we only need
to back-patch a small fragment of commit 5b7b5518d, which fixes failure to
propagate out the original WHERE clauses when a broken EC contains constant
members. (The regression test case results show that these older branches
are noticeably stupider than 9.2+ in terms of the quality of the plans
generated; but we don't really care about plan quality in such cases,
only that the plan not be outright wrong. A more invasive fix in the
older branches would not be a good idea anyway from a plan-stability
standpoint.)
2014-10-02 01:30:24 +02:00
|
|
|
-> Seq Scan on ec2
|
2015-03-30 20:59:49 +02:00
|
|
|
Filter: ('42'::bigint = x1)
|
Fix some more problems with nested append relations.
As of commit a87c72915 (which later got backpatched as far as 9.1),
we're explicitly supporting the notion that append relations can be
nested; this can occur when UNION ALL constructs are nested, or when
a UNION ALL contains a table with inheritance children.
Bug #11457 from Nelson Page, as well as an earlier report from Elvis
Pranskevichus, showed that there were still nasty bugs associated with such
cases: in particular the EquivalenceClass mechanism could try to generate
"join" clauses connecting an appendrel child to some grandparent appendrel,
which would result in assertion failures or bogus plans.
Upon investigation I concluded that all current callers of
find_childrel_appendrelinfo() need to be fixed to explicitly consider
multiple levels of parent appendrels. The most complex fix was in
processing of "broken" EquivalenceClasses, which are ECs for which we have
been unable to generate all the derived equality clauses we would like to
because of missing cross-type equality operators in the underlying btree
operator family. That code path is more or less entirely untested by
the regression tests to date, because no standard opfamilies have such
holes in them. So I wrote a new regression test script to try to exercise
it a bit, which turned out to be quite a worthwhile activity as it exposed
existing bugs in all supported branches.
The present patch is essentially the same as far back as 9.2, which is
where parameterized paths were introduced. In 9.0 and 9.1, we only need
to back-patch a small fragment of commit 5b7b5518d, which fixes failure to
propagate out the original WHERE clauses when a broken EC contains constant
members. (The regression test case results show that these older branches
are noticeably stupider than 9.2+ in terms of the quality of the plans
generated; but we don't really care about plan quality in such cases,
only that the plan not be outright wrong. A more invasive fix in the
older branches would not be a good idea anyway from a plan-stability
standpoint.)
2014-10-02 01:30:24 +02:00
|
|
|
(6 rows)
|
|
|
|
|
|
|
|
explain (costs off)
|
|
|
|
select * from ec1, ec2 where ff = x1 and x1 = '42'::int8alias1;
|
|
|
|
QUERY PLAN
|
|
|
|
---------------------------------------------
|
|
|
|
Nested Loop
|
|
|
|
-> Index Scan using ec1_pkey on ec1
|
|
|
|
Index Cond: (ff = '42'::int8alias1)
|
|
|
|
-> Seq Scan on ec2
|
|
|
|
Filter: (x1 = '42'::int8alias1)
|
|
|
|
(5 rows)
|
|
|
|
|
|
|
|
explain (costs off)
|
|
|
|
select * from ec1, ec2 where ff = x1 and x1 = '42'::int8alias2;
|
|
|
|
QUERY PLAN
|
|
|
|
-----------------------------------------
|
|
|
|
Nested Loop
|
|
|
|
-> Seq Scan on ec2
|
|
|
|
Filter: (x1 = '42'::int8alias2)
|
|
|
|
-> Index Scan using ec1_pkey on ec1
|
|
|
|
Index Cond: (ff = ec2.x1)
|
|
|
|
(5 rows)
|
|
|
|
|
|
|
|
create unique index ec1_expr1 on ec1((ff + 1));
|
|
|
|
create unique index ec1_expr2 on ec1((ff + 2 + 1));
|
|
|
|
create unique index ec1_expr3 on ec1((ff + 3 + 1));
|
|
|
|
create unique index ec1_expr4 on ec1((ff + 4));
|
|
|
|
explain (costs off)
|
|
|
|
select * from ec1,
|
|
|
|
(select ff + 1 as x from
|
|
|
|
(select ff + 2 as ff from ec1
|
|
|
|
union all
|
|
|
|
select ff + 3 as ff from ec1) ss0
|
|
|
|
union all
|
|
|
|
select ff + 4 as x from ec1) as ss1
|
|
|
|
where ss1.x = ec1.f1 and ec1.ff = 42::int8;
|
|
|
|
QUERY PLAN
|
|
|
|
-----------------------------------------------------
|
|
|
|
Nested Loop
|
|
|
|
-> Index Scan using ec1_pkey on ec1
|
2015-03-30 20:59:49 +02:00
|
|
|
Index Cond: (ff = '42'::bigint)
|
Fix some more problems with nested append relations.
As of commit a87c72915 (which later got backpatched as far as 9.1),
we're explicitly supporting the notion that append relations can be
nested; this can occur when UNION ALL constructs are nested, or when
a UNION ALL contains a table with inheritance children.
Bug #11457 from Nelson Page, as well as an earlier report from Elvis
Pranskevichus, showed that there were still nasty bugs associated with such
cases: in particular the EquivalenceClass mechanism could try to generate
"join" clauses connecting an appendrel child to some grandparent appendrel,
which would result in assertion failures or bogus plans.
Upon investigation I concluded that all current callers of
find_childrel_appendrelinfo() need to be fixed to explicitly consider
multiple levels of parent appendrels. The most complex fix was in
processing of "broken" EquivalenceClasses, which are ECs for which we have
been unable to generate all the derived equality clauses we would like to
because of missing cross-type equality operators in the underlying btree
operator family. That code path is more or less entirely untested by
the regression tests to date, because no standard opfamilies have such
holes in them. So I wrote a new regression test script to try to exercise
it a bit, which turned out to be quite a worthwhile activity as it exposed
existing bugs in all supported branches.
The present patch is essentially the same as far back as 9.2, which is
where parameterized paths were introduced. In 9.0 and 9.1, we only need
to back-patch a small fragment of commit 5b7b5518d, which fixes failure to
propagate out the original WHERE clauses when a broken EC contains constant
members. (The regression test case results show that these older branches
are noticeably stupider than 9.2+ in terms of the quality of the plans
generated; but we don't really care about plan quality in such cases,
only that the plan not be outright wrong. A more invasive fix in the
older branches would not be a good idea anyway from a plan-stability
standpoint.)
2014-10-02 01:30:24 +02:00
|
|
|
-> Append
|
|
|
|
-> Index Scan using ec1_expr2 on ec1 ec1_1
|
|
|
|
Index Cond: (((ff + 2) + 1) = ec1.f1)
|
|
|
|
-> Index Scan using ec1_expr3 on ec1 ec1_2
|
|
|
|
Index Cond: (((ff + 3) + 1) = ec1.f1)
|
|
|
|
-> Index Scan using ec1_expr4 on ec1 ec1_3
|
|
|
|
Index Cond: ((ff + 4) = ec1.f1)
|
|
|
|
(10 rows)
|
|
|
|
|
|
|
|
explain (costs off)
|
|
|
|
select * from ec1,
|
|
|
|
(select ff + 1 as x from
|
|
|
|
(select ff + 2 as ff from ec1
|
|
|
|
union all
|
|
|
|
select ff + 3 as ff from ec1) ss0
|
|
|
|
union all
|
|
|
|
select ff + 4 as x from ec1) as ss1
|
|
|
|
where ss1.x = ec1.f1 and ec1.ff = 42::int8 and ec1.ff = ec1.f1;
|
2015-03-30 20:59:49 +02:00
|
|
|
QUERY PLAN
|
|
|
|
-------------------------------------------------------------------
|
Fix some more problems with nested append relations.
As of commit a87c72915 (which later got backpatched as far as 9.1),
we're explicitly supporting the notion that append relations can be
nested; this can occur when UNION ALL constructs are nested, or when
a UNION ALL contains a table with inheritance children.
Bug #11457 from Nelson Page, as well as an earlier report from Elvis
Pranskevichus, showed that there were still nasty bugs associated with such
cases: in particular the EquivalenceClass mechanism could try to generate
"join" clauses connecting an appendrel child to some grandparent appendrel,
which would result in assertion failures or bogus plans.
Upon investigation I concluded that all current callers of
find_childrel_appendrelinfo() need to be fixed to explicitly consider
multiple levels of parent appendrels. The most complex fix was in
processing of "broken" EquivalenceClasses, which are ECs for which we have
been unable to generate all the derived equality clauses we would like to
because of missing cross-type equality operators in the underlying btree
operator family. That code path is more or less entirely untested by
the regression tests to date, because no standard opfamilies have such
holes in them. So I wrote a new regression test script to try to exercise
it a bit, which turned out to be quite a worthwhile activity as it exposed
existing bugs in all supported branches.
The present patch is essentially the same as far back as 9.2, which is
where parameterized paths were introduced. In 9.0 and 9.1, we only need
to back-patch a small fragment of commit 5b7b5518d, which fixes failure to
propagate out the original WHERE clauses when a broken EC contains constant
members. (The regression test case results show that these older branches
are noticeably stupider than 9.2+ in terms of the quality of the plans
generated; but we don't really care about plan quality in such cases,
only that the plan not be outright wrong. A more invasive fix in the
older branches would not be a good idea anyway from a plan-stability
standpoint.)
2014-10-02 01:30:24 +02:00
|
|
|
Nested Loop
|
|
|
|
Join Filter: ((((ec1_1.ff + 2) + 1)) = ec1.f1)
|
|
|
|
-> Index Scan using ec1_pkey on ec1
|
2015-03-30 20:59:49 +02:00
|
|
|
Index Cond: ((ff = '42'::bigint) AND (ff = '42'::bigint))
|
Fix some more problems with nested append relations.
As of commit a87c72915 (which later got backpatched as far as 9.1),
we're explicitly supporting the notion that append relations can be
nested; this can occur when UNION ALL constructs are nested, or when
a UNION ALL contains a table with inheritance children.
Bug #11457 from Nelson Page, as well as an earlier report from Elvis
Pranskevichus, showed that there were still nasty bugs associated with such
cases: in particular the EquivalenceClass mechanism could try to generate
"join" clauses connecting an appendrel child to some grandparent appendrel,
which would result in assertion failures or bogus plans.
Upon investigation I concluded that all current callers of
find_childrel_appendrelinfo() need to be fixed to explicitly consider
multiple levels of parent appendrels. The most complex fix was in
processing of "broken" EquivalenceClasses, which are ECs for which we have
been unable to generate all the derived equality clauses we would like to
because of missing cross-type equality operators in the underlying btree
operator family. That code path is more or less entirely untested by
the regression tests to date, because no standard opfamilies have such
holes in them. So I wrote a new regression test script to try to exercise
it a bit, which turned out to be quite a worthwhile activity as it exposed
existing bugs in all supported branches.
The present patch is essentially the same as far back as 9.2, which is
where parameterized paths were introduced. In 9.0 and 9.1, we only need
to back-patch a small fragment of commit 5b7b5518d, which fixes failure to
propagate out the original WHERE clauses when a broken EC contains constant
members. (The regression test case results show that these older branches
are noticeably stupider than 9.2+ in terms of the quality of the plans
generated; but we don't really care about plan quality in such cases,
only that the plan not be outright wrong. A more invasive fix in the
older branches would not be a good idea anyway from a plan-stability
standpoint.)
2014-10-02 01:30:24 +02:00
|
|
|
Filter: (ff = f1)
|
|
|
|
-> Append
|
|
|
|
-> Index Scan using ec1_expr2 on ec1 ec1_1
|
2015-03-30 20:59:49 +02:00
|
|
|
Index Cond: (((ff + 2) + 1) = '42'::bigint)
|
Fix some more problems with nested append relations.
As of commit a87c72915 (which later got backpatched as far as 9.1),
we're explicitly supporting the notion that append relations can be
nested; this can occur when UNION ALL constructs are nested, or when
a UNION ALL contains a table with inheritance children.
Bug #11457 from Nelson Page, as well as an earlier report from Elvis
Pranskevichus, showed that there were still nasty bugs associated with such
cases: in particular the EquivalenceClass mechanism could try to generate
"join" clauses connecting an appendrel child to some grandparent appendrel,
which would result in assertion failures or bogus plans.
Upon investigation I concluded that all current callers of
find_childrel_appendrelinfo() need to be fixed to explicitly consider
multiple levels of parent appendrels. The most complex fix was in
processing of "broken" EquivalenceClasses, which are ECs for which we have
been unable to generate all the derived equality clauses we would like to
because of missing cross-type equality operators in the underlying btree
operator family. That code path is more or less entirely untested by
the regression tests to date, because no standard opfamilies have such
holes in them. So I wrote a new regression test script to try to exercise
it a bit, which turned out to be quite a worthwhile activity as it exposed
existing bugs in all supported branches.
The present patch is essentially the same as far back as 9.2, which is
where parameterized paths were introduced. In 9.0 and 9.1, we only need
to back-patch a small fragment of commit 5b7b5518d, which fixes failure to
propagate out the original WHERE clauses when a broken EC contains constant
members. (The regression test case results show that these older branches
are noticeably stupider than 9.2+ in terms of the quality of the plans
generated; but we don't really care about plan quality in such cases,
only that the plan not be outright wrong. A more invasive fix in the
older branches would not be a good idea anyway from a plan-stability
standpoint.)
2014-10-02 01:30:24 +02:00
|
|
|
-> Index Scan using ec1_expr3 on ec1 ec1_2
|
2015-03-30 20:59:49 +02:00
|
|
|
Index Cond: (((ff + 3) + 1) = '42'::bigint)
|
Fix some more problems with nested append relations.
As of commit a87c72915 (which later got backpatched as far as 9.1),
we're explicitly supporting the notion that append relations can be
nested; this can occur when UNION ALL constructs are nested, or when
a UNION ALL contains a table with inheritance children.
Bug #11457 from Nelson Page, as well as an earlier report from Elvis
Pranskevichus, showed that there were still nasty bugs associated with such
cases: in particular the EquivalenceClass mechanism could try to generate
"join" clauses connecting an appendrel child to some grandparent appendrel,
which would result in assertion failures or bogus plans.
Upon investigation I concluded that all current callers of
find_childrel_appendrelinfo() need to be fixed to explicitly consider
multiple levels of parent appendrels. The most complex fix was in
processing of "broken" EquivalenceClasses, which are ECs for which we have
been unable to generate all the derived equality clauses we would like to
because of missing cross-type equality operators in the underlying btree
operator family. That code path is more or less entirely untested by
the regression tests to date, because no standard opfamilies have such
holes in them. So I wrote a new regression test script to try to exercise
it a bit, which turned out to be quite a worthwhile activity as it exposed
existing bugs in all supported branches.
The present patch is essentially the same as far back as 9.2, which is
where parameterized paths were introduced. In 9.0 and 9.1, we only need
to back-patch a small fragment of commit 5b7b5518d, which fixes failure to
propagate out the original WHERE clauses when a broken EC contains constant
members. (The regression test case results show that these older branches
are noticeably stupider than 9.2+ in terms of the quality of the plans
generated; but we don't really care about plan quality in such cases,
only that the plan not be outright wrong. A more invasive fix in the
older branches would not be a good idea anyway from a plan-stability
standpoint.)
2014-10-02 01:30:24 +02:00
|
|
|
-> Index Scan using ec1_expr4 on ec1 ec1_3
|
2015-03-30 20:59:49 +02:00
|
|
|
Index Cond: ((ff + 4) = '42'::bigint)
|
Fix some more problems with nested append relations.
As of commit a87c72915 (which later got backpatched as far as 9.1),
we're explicitly supporting the notion that append relations can be
nested; this can occur when UNION ALL constructs are nested, or when
a UNION ALL contains a table with inheritance children.
Bug #11457 from Nelson Page, as well as an earlier report from Elvis
Pranskevichus, showed that there were still nasty bugs associated with such
cases: in particular the EquivalenceClass mechanism could try to generate
"join" clauses connecting an appendrel child to some grandparent appendrel,
which would result in assertion failures or bogus plans.
Upon investigation I concluded that all current callers of
find_childrel_appendrelinfo() need to be fixed to explicitly consider
multiple levels of parent appendrels. The most complex fix was in
processing of "broken" EquivalenceClasses, which are ECs for which we have
been unable to generate all the derived equality clauses we would like to
because of missing cross-type equality operators in the underlying btree
operator family. That code path is more or less entirely untested by
the regression tests to date, because no standard opfamilies have such
holes in them. So I wrote a new regression test script to try to exercise
it a bit, which turned out to be quite a worthwhile activity as it exposed
existing bugs in all supported branches.
The present patch is essentially the same as far back as 9.2, which is
where parameterized paths were introduced. In 9.0 and 9.1, we only need
to back-patch a small fragment of commit 5b7b5518d, which fixes failure to
propagate out the original WHERE clauses when a broken EC contains constant
members. (The regression test case results show that these older branches
are noticeably stupider than 9.2+ in terms of the quality of the plans
generated; but we don't really care about plan quality in such cases,
only that the plan not be outright wrong. A more invasive fix in the
older branches would not be a good idea anyway from a plan-stability
standpoint.)
2014-10-02 01:30:24 +02:00
|
|
|
(12 rows)
|
|
|
|
|
|
|
|
explain (costs off)
|
|
|
|
select * from ec1,
|
|
|
|
(select ff + 1 as x from
|
|
|
|
(select ff + 2 as ff from ec1
|
|
|
|
union all
|
|
|
|
select ff + 3 as ff from ec1) ss0
|
|
|
|
union all
|
|
|
|
select ff + 4 as x from ec1) as ss1,
|
|
|
|
(select ff + 1 as x from
|
|
|
|
(select ff + 2 as ff from ec1
|
|
|
|
union all
|
|
|
|
select ff + 3 as ff from ec1) ss0
|
|
|
|
union all
|
|
|
|
select ff + 4 as x from ec1) as ss2
|
|
|
|
where ss1.x = ec1.f1 and ss1.x = ss2.x and ec1.ff = 42::int8;
|
|
|
|
QUERY PLAN
|
|
|
|
---------------------------------------------------------------------
|
|
|
|
Nested Loop
|
|
|
|
-> Nested Loop
|
|
|
|
-> Index Scan using ec1_pkey on ec1
|
2015-03-30 20:59:49 +02:00
|
|
|
Index Cond: (ff = '42'::bigint)
|
Fix some more problems with nested append relations.
As of commit a87c72915 (which later got backpatched as far as 9.1),
we're explicitly supporting the notion that append relations can be
nested; this can occur when UNION ALL constructs are nested, or when
a UNION ALL contains a table with inheritance children.
Bug #11457 from Nelson Page, as well as an earlier report from Elvis
Pranskevichus, showed that there were still nasty bugs associated with such
cases: in particular the EquivalenceClass mechanism could try to generate
"join" clauses connecting an appendrel child to some grandparent appendrel,
which would result in assertion failures or bogus plans.
Upon investigation I concluded that all current callers of
find_childrel_appendrelinfo() need to be fixed to explicitly consider
multiple levels of parent appendrels. The most complex fix was in
processing of "broken" EquivalenceClasses, which are ECs for which we have
been unable to generate all the derived equality clauses we would like to
because of missing cross-type equality operators in the underlying btree
operator family. That code path is more or less entirely untested by
the regression tests to date, because no standard opfamilies have such
holes in them. So I wrote a new regression test script to try to exercise
it a bit, which turned out to be quite a worthwhile activity as it exposed
existing bugs in all supported branches.
The present patch is essentially the same as far back as 9.2, which is
where parameterized paths were introduced. In 9.0 and 9.1, we only need
to back-patch a small fragment of commit 5b7b5518d, which fixes failure to
propagate out the original WHERE clauses when a broken EC contains constant
members. (The regression test case results show that these older branches
are noticeably stupider than 9.2+ in terms of the quality of the plans
generated; but we don't really care about plan quality in such cases,
only that the plan not be outright wrong. A more invasive fix in the
older branches would not be a good idea anyway from a plan-stability
standpoint.)
2014-10-02 01:30:24 +02:00
|
|
|
-> Append
|
|
|
|
-> Index Scan using ec1_expr2 on ec1 ec1_1
|
|
|
|
Index Cond: (((ff + 2) + 1) = ec1.f1)
|
|
|
|
-> Index Scan using ec1_expr3 on ec1 ec1_2
|
|
|
|
Index Cond: (((ff + 3) + 1) = ec1.f1)
|
|
|
|
-> Index Scan using ec1_expr4 on ec1 ec1_3
|
|
|
|
Index Cond: ((ff + 4) = ec1.f1)
|
|
|
|
-> Append
|
|
|
|
-> Index Scan using ec1_expr2 on ec1 ec1_4
|
|
|
|
Index Cond: (((ff + 2) + 1) = (((ec1_1.ff + 2) + 1)))
|
|
|
|
-> Index Scan using ec1_expr3 on ec1 ec1_5
|
|
|
|
Index Cond: (((ff + 3) + 1) = (((ec1_1.ff + 2) + 1)))
|
|
|
|
-> Index Scan using ec1_expr4 on ec1 ec1_6
|
|
|
|
Index Cond: ((ff + 4) = (((ec1_1.ff + 2) + 1)))
|
|
|
|
(18 rows)
|
|
|
|
|
|
|
|
-- let's try that as a mergejoin
|
|
|
|
set enable_mergejoin = on;
|
|
|
|
set enable_nestloop = off;
|
|
|
|
explain (costs off)
|
|
|
|
select * from ec1,
|
|
|
|
(select ff + 1 as x from
|
|
|
|
(select ff + 2 as ff from ec1
|
|
|
|
union all
|
|
|
|
select ff + 3 as ff from ec1) ss0
|
|
|
|
union all
|
|
|
|
select ff + 4 as x from ec1) as ss1,
|
|
|
|
(select ff + 1 as x from
|
|
|
|
(select ff + 2 as ff from ec1
|
|
|
|
union all
|
|
|
|
select ff + 3 as ff from ec1) ss0
|
|
|
|
union all
|
|
|
|
select ff + 4 as x from ec1) as ss2
|
|
|
|
where ss1.x = ec1.f1 and ss1.x = ss2.x and ec1.ff = 42::int8;
|
|
|
|
QUERY PLAN
|
|
|
|
-----------------------------------------------------------------
|
|
|
|
Merge Join
|
|
|
|
Merge Cond: ((((ec1_4.ff + 2) + 1)) = (((ec1_1.ff + 2) + 1)))
|
|
|
|
-> Merge Append
|
|
|
|
Sort Key: (((ec1_4.ff + 2) + 1))
|
|
|
|
-> Index Scan using ec1_expr2 on ec1 ec1_4
|
|
|
|
-> Index Scan using ec1_expr3 on ec1 ec1_5
|
|
|
|
-> Index Scan using ec1_expr4 on ec1 ec1_6
|
|
|
|
-> Materialize
|
|
|
|
-> Merge Join
|
|
|
|
Merge Cond: ((((ec1_1.ff + 2) + 1)) = ec1.f1)
|
|
|
|
-> Merge Append
|
|
|
|
Sort Key: (((ec1_1.ff + 2) + 1))
|
|
|
|
-> Index Scan using ec1_expr2 on ec1 ec1_1
|
|
|
|
-> Index Scan using ec1_expr3 on ec1 ec1_2
|
|
|
|
-> Index Scan using ec1_expr4 on ec1 ec1_3
|
2017-04-08 04:20:03 +02:00
|
|
|
-> Sort
|
|
|
|
Sort Key: ec1.f1 USING <
|
|
|
|
-> Index Scan using ec1_pkey on ec1
|
|
|
|
Index Cond: (ff = '42'::bigint)
|
|
|
|
(19 rows)
|
Fix some more problems with nested append relations.
As of commit a87c72915 (which later got backpatched as far as 9.1),
we're explicitly supporting the notion that append relations can be
nested; this can occur when UNION ALL constructs are nested, or when
a UNION ALL contains a table with inheritance children.
Bug #11457 from Nelson Page, as well as an earlier report from Elvis
Pranskevichus, showed that there were still nasty bugs associated with such
cases: in particular the EquivalenceClass mechanism could try to generate
"join" clauses connecting an appendrel child to some grandparent appendrel,
which would result in assertion failures or bogus plans.
Upon investigation I concluded that all current callers of
find_childrel_appendrelinfo() need to be fixed to explicitly consider
multiple levels of parent appendrels. The most complex fix was in
processing of "broken" EquivalenceClasses, which are ECs for which we have
been unable to generate all the derived equality clauses we would like to
because of missing cross-type equality operators in the underlying btree
operator family. That code path is more or less entirely untested by
the regression tests to date, because no standard opfamilies have such
holes in them. So I wrote a new regression test script to try to exercise
it a bit, which turned out to be quite a worthwhile activity as it exposed
existing bugs in all supported branches.
The present patch is essentially the same as far back as 9.2, which is
where parameterized paths were introduced. In 9.0 and 9.1, we only need
to back-patch a small fragment of commit 5b7b5518d, which fixes failure to
propagate out the original WHERE clauses when a broken EC contains constant
members. (The regression test case results show that these older branches
are noticeably stupider than 9.2+ in terms of the quality of the plans
generated; but we don't really care about plan quality in such cases,
only that the plan not be outright wrong. A more invasive fix in the
older branches would not be a good idea anyway from a plan-stability
standpoint.)
2014-10-02 01:30:24 +02:00
|
|
|
|
|
|
|
-- check partially indexed scan
|
|
|
|
set enable_nestloop = on;
|
|
|
|
set enable_mergejoin = off;
|
|
|
|
drop index ec1_expr3;
|
|
|
|
explain (costs off)
|
|
|
|
select * from ec1,
|
|
|
|
(select ff + 1 as x from
|
|
|
|
(select ff + 2 as ff from ec1
|
|
|
|
union all
|
|
|
|
select ff + 3 as ff from ec1) ss0
|
|
|
|
union all
|
|
|
|
select ff + 4 as x from ec1) as ss1
|
|
|
|
where ss1.x = ec1.f1 and ec1.ff = 42::int8;
|
|
|
|
QUERY PLAN
|
|
|
|
-----------------------------------------------------
|
|
|
|
Nested Loop
|
|
|
|
-> Index Scan using ec1_pkey on ec1
|
2015-03-30 20:59:49 +02:00
|
|
|
Index Cond: (ff = '42'::bigint)
|
Fix some more problems with nested append relations.
As of commit a87c72915 (which later got backpatched as far as 9.1),
we're explicitly supporting the notion that append relations can be
nested; this can occur when UNION ALL constructs are nested, or when
a UNION ALL contains a table with inheritance children.
Bug #11457 from Nelson Page, as well as an earlier report from Elvis
Pranskevichus, showed that there were still nasty bugs associated with such
cases: in particular the EquivalenceClass mechanism could try to generate
"join" clauses connecting an appendrel child to some grandparent appendrel,
which would result in assertion failures or bogus plans.
Upon investigation I concluded that all current callers of
find_childrel_appendrelinfo() need to be fixed to explicitly consider
multiple levels of parent appendrels. The most complex fix was in
processing of "broken" EquivalenceClasses, which are ECs for which we have
been unable to generate all the derived equality clauses we would like to
because of missing cross-type equality operators in the underlying btree
operator family. That code path is more or less entirely untested by
the regression tests to date, because no standard opfamilies have such
holes in them. So I wrote a new regression test script to try to exercise
it a bit, which turned out to be quite a worthwhile activity as it exposed
existing bugs in all supported branches.
The present patch is essentially the same as far back as 9.2, which is
where parameterized paths were introduced. In 9.0 and 9.1, we only need
to back-patch a small fragment of commit 5b7b5518d, which fixes failure to
propagate out the original WHERE clauses when a broken EC contains constant
members. (The regression test case results show that these older branches
are noticeably stupider than 9.2+ in terms of the quality of the plans
generated; but we don't really care about plan quality in such cases,
only that the plan not be outright wrong. A more invasive fix in the
older branches would not be a good idea anyway from a plan-stability
standpoint.)
2014-10-02 01:30:24 +02:00
|
|
|
-> Append
|
|
|
|
-> Index Scan using ec1_expr2 on ec1 ec1_1
|
|
|
|
Index Cond: (((ff + 2) + 1) = ec1.f1)
|
|
|
|
-> Seq Scan on ec1 ec1_2
|
|
|
|
Filter: (((ff + 3) + 1) = ec1.f1)
|
|
|
|
-> Index Scan using ec1_expr4 on ec1 ec1_3
|
|
|
|
Index Cond: ((ff + 4) = ec1.f1)
|
|
|
|
(10 rows)
|
|
|
|
|
|
|
|
-- let's try that as a mergejoin
|
|
|
|
set enable_mergejoin = on;
|
|
|
|
set enable_nestloop = off;
|
|
|
|
explain (costs off)
|
|
|
|
select * from ec1,
|
|
|
|
(select ff + 1 as x from
|
|
|
|
(select ff + 2 as ff from ec1
|
|
|
|
union all
|
|
|
|
select ff + 3 as ff from ec1) ss0
|
|
|
|
union all
|
|
|
|
select ff + 4 as x from ec1) as ss1
|
|
|
|
where ss1.x = ec1.f1 and ec1.ff = 42::int8;
|
|
|
|
QUERY PLAN
|
|
|
|
-----------------------------------------------------
|
|
|
|
Merge Join
|
|
|
|
Merge Cond: ((((ec1_1.ff + 2) + 1)) = ec1.f1)
|
|
|
|
-> Merge Append
|
|
|
|
Sort Key: (((ec1_1.ff + 2) + 1))
|
|
|
|
-> Index Scan using ec1_expr2 on ec1 ec1_1
|
|
|
|
-> Sort
|
|
|
|
Sort Key: (((ec1_2.ff + 3) + 1))
|
|
|
|
-> Seq Scan on ec1 ec1_2
|
|
|
|
-> Index Scan using ec1_expr4 on ec1 ec1_3
|
2017-04-08 04:20:03 +02:00
|
|
|
-> Sort
|
|
|
|
Sort Key: ec1.f1 USING <
|
|
|
|
-> Index Scan using ec1_pkey on ec1
|
|
|
|
Index Cond: (ff = '42'::bigint)
|
|
|
|
(13 rows)
|
Fix some more problems with nested append relations.
As of commit a87c72915 (which later got backpatched as far as 9.1),
we're explicitly supporting the notion that append relations can be
nested; this can occur when UNION ALL constructs are nested, or when
a UNION ALL contains a table with inheritance children.
Bug #11457 from Nelson Page, as well as an earlier report from Elvis
Pranskevichus, showed that there were still nasty bugs associated with such
cases: in particular the EquivalenceClass mechanism could try to generate
"join" clauses connecting an appendrel child to some grandparent appendrel,
which would result in assertion failures or bogus plans.
Upon investigation I concluded that all current callers of
find_childrel_appendrelinfo() need to be fixed to explicitly consider
multiple levels of parent appendrels. The most complex fix was in
processing of "broken" EquivalenceClasses, which are ECs for which we have
been unable to generate all the derived equality clauses we would like to
because of missing cross-type equality operators in the underlying btree
operator family. That code path is more or less entirely untested by
the regression tests to date, because no standard opfamilies have such
holes in them. So I wrote a new regression test script to try to exercise
it a bit, which turned out to be quite a worthwhile activity as it exposed
existing bugs in all supported branches.
The present patch is essentially the same as far back as 9.2, which is
where parameterized paths were introduced. In 9.0 and 9.1, we only need
to back-patch a small fragment of commit 5b7b5518d, which fixes failure to
propagate out the original WHERE clauses when a broken EC contains constant
members. (The regression test case results show that these older branches
are noticeably stupider than 9.2+ in terms of the quality of the plans
generated; but we don't really care about plan quality in such cases,
only that the plan not be outright wrong. A more invasive fix in the
older branches would not be a good idea anyway from a plan-stability
standpoint.)
2014-10-02 01:30:24 +02:00
|
|
|
|
Improve RLS planning by marking individual quals with security levels.
In an RLS query, we must ensure that security filter quals are evaluated
before ordinary query quals, in case the latter contain "leaky" functions
that could expose the contents of sensitive rows. The original
implementation of RLS planning ensured this by pushing the scan of a
secured table into a sub-query that it marked as a security-barrier view.
Unfortunately this results in very inefficient plans in many cases, because
the sub-query cannot be flattened and gets planned independently of the
rest of the query.
To fix, drop the use of sub-queries to enforce RLS qual order, and instead
mark each qual (RestrictInfo) with a security_level field establishing its
priority for evaluation. Quals must be evaluated in security_level order,
except that "leakproof" quals can be allowed to go ahead of quals of lower
security_level, if it's helpful to do so. This has to be enforced within
the ordering of any one list of quals to be evaluated at a table scan node,
and we also have to ensure that quals are not chosen for early evaluation
(i.e., use as an index qual or TID scan qual) if they're not allowed to go
ahead of other quals at the scan node.
This is sufficient to fix the problem for RLS quals, since we only support
RLS policies on simple tables and thus RLS quals will always exist at the
table scan level only. Eventually these qual ordering rules should be
enforced for join quals as well, which would permit improving planning for
explicit security-barrier views; but that's a task for another patch.
Note that FDWs would need to be aware of these rules --- and not, for
example, send an insecure qual for remote execution --- but since we do
not yet allow RLS policies on foreign tables, the case doesn't arise.
This will need to be addressed before we can allow such policies.
Patch by me, reviewed by Stephen Frost and Dean Rasheed.
Discussion: https://postgr.es/m/8185.1477432701@sss.pgh.pa.us
2017-01-18 18:58:20 +01:00
|
|
|
-- check effects of row-level security
|
|
|
|
set enable_nestloop = on;
|
|
|
|
set enable_mergejoin = off;
|
|
|
|
alter table ec1 enable row level security;
|
|
|
|
create policy p1 on ec1 using (f1 < '5'::int8alias1);
|
|
|
|
create user regress_user_ectest;
|
|
|
|
grant select on ec0 to regress_user_ectest;
|
|
|
|
grant select on ec1 to regress_user_ectest;
|
|
|
|
-- without any RLS, we'll treat {a.ff, b.ff, 43} as an EquivalenceClass
|
|
|
|
explain (costs off)
|
|
|
|
select * from ec0 a, ec1 b
|
|
|
|
where a.ff = b.ff and a.ff = 43::bigint::int8alias1;
|
|
|
|
QUERY PLAN
|
|
|
|
---------------------------------------------
|
|
|
|
Nested Loop
|
|
|
|
-> Index Scan using ec0_pkey on ec0 a
|
|
|
|
Index Cond: (ff = '43'::int8alias1)
|
|
|
|
-> Index Scan using ec1_pkey on ec1 b
|
|
|
|
Index Cond: (ff = '43'::int8alias1)
|
|
|
|
(5 rows)
|
|
|
|
|
|
|
|
set session authorization regress_user_ectest;
|
|
|
|
-- with RLS active, the non-leakproof a.ff = 43 clause is not treated
|
|
|
|
-- as a suitable source for an EquivalenceClass; currently, this is true
|
|
|
|
-- even though the RLS clause has nothing to do directly with the EC
|
|
|
|
explain (costs off)
|
|
|
|
select * from ec0 a, ec1 b
|
|
|
|
where a.ff = b.ff and a.ff = 43::bigint::int8alias1;
|
|
|
|
QUERY PLAN
|
|
|
|
---------------------------------------------
|
|
|
|
Nested Loop
|
|
|
|
-> Index Scan using ec0_pkey on ec0 a
|
|
|
|
Index Cond: (ff = '43'::int8alias1)
|
|
|
|
-> Index Scan using ec1_pkey on ec1 b
|
|
|
|
Index Cond: (ff = a.ff)
|
|
|
|
Filter: (f1 < '5'::int8alias1)
|
|
|
|
(6 rows)
|
|
|
|
|
|
|
|
reset session authorization;
|
|
|
|
revoke select on ec0 from regress_user_ectest;
|
|
|
|
revoke select on ec1 from regress_user_ectest;
|
|
|
|
drop user regress_user_ectest;
|
Reduce "X = X" to "X IS NOT NULL", if it's easy to do so.
If the operator is a strict btree equality operator, and X isn't volatile,
then the clause must yield true for any non-null value of X, or null if X
is null. At top level of a WHERE clause, we can ignore the distinction
between false and null results, so it's valid to simplify the clause to
"X IS NOT NULL". This is a useful improvement mainly because we'll get
a far better selectivity estimate in most cases.
Because such cases seldom arise in well-written queries, it is unappetizing
to expend a lot of planner cycles looking for them ... but it turns out
that there's a place we can shoehorn this in practically for free, because
equivclass.c already has to detect and reject candidate equivalences of the
form X = X. That doesn't catch every place that it would be valid to
simplify to X IS NOT NULL, but it catches the typical case. Working harder
doesn't seem justified.
Patch by me, reviewed by Petr Jelinek
Discussion: https://postgr.es/m/CAMjNa7cC4X9YR-vAJS-jSYCajhRDvJQnN7m2sLH1wLh-_Z2bsw@mail.gmail.com
2017-10-08 18:23:32 +02:00
|
|
|
-- check that X=X is converted to X IS NOT NULL when appropriate
|
|
|
|
explain (costs off)
|
|
|
|
select * from tenk1 where unique1 = unique1 and unique2 = unique2;
|
|
|
|
QUERY PLAN
|
|
|
|
-------------------------------------------------------------
|
|
|
|
Seq Scan on tenk1
|
|
|
|
Filter: ((unique1 IS NOT NULL) AND (unique2 IS NOT NULL))
|
|
|
|
(2 rows)
|
|
|
|
|
Remove useless self-joins
The Self Join Elimination (SJE) feature removes an inner join of a plain table
to itself in the query tree if is proved that the join can be replaced with
a scan without impacting the query result. Self join and inner relation are
replaced with the outer in query, equivalence classes, and planner info
structures. Also, inner restrictlist moves to the outer one with removing
duplicated clauses. Thus, this optimization reduces the length of the range
table list (this especially makes sense for partitioned relations), reduces
the number of restriction clauses === selectivity estimations, and potentially
can improve total planner prediction for the query.
The SJE proof is based on innerrel_is_unique machinery.
We can remove a self-join when for each outer row:
1. At most one inner row matches the join clause.
2. Each matched inner row must be (physically) the same row as the outer one.
In this patch we use the next approach to identify a self-join:
1. Collect all merge-joinable join quals which look like a.x = b.x
2. Add to the list above the baseretrictinfo of the inner table.
3. Check innerrel_is_unique() for the qual list. If it returns false, skip
this pair of joining tables.
4. Check uniqueness, proved by the baserestrictinfo clauses. To prove
the possibility of self-join elimination inner and outer clauses must have
an exact match.
The relation replacement procedure is not trivial and it is partly combined
with the one, used to remove useless left joins. Tests, covering this feature,
were added to join.sql. Some regression tests changed due to self-join removal
logic.
Discussion: https://postgr.es/m/flat/64486b0b-0404-e39e-322d-0801154901f3%40postgrespro.ru
Author: Andrey Lepikhov, Alexander Kuzmenkov
Reviewed-by: Tom Lane, Robert Haas, Andres Freund, Simon Riggs, Jonathan S. Katz
Reviewed-by: David Rowley, Thomas Munro, Konstantin Knizhnik, Heikki Linnakangas
Reviewed-by: Hywel Carver, Laurenz Albe, Ronan Dunklau, vignesh C, Zhihong Yu
Reviewed-by: Greg Stark, Jaime Casanova, Michał Kłeczek, Alena Rybakina
Reviewed-by: Alexander Korotkov
2023-10-25 11:46:22 +02:00
|
|
|
-- Test that broken ECs are processed correctly during self join removal.
|
|
|
|
-- Disable merge joins so that we don't get an error about missing commutator.
|
|
|
|
-- Test both orientations of the join clause, because only one of them breaks
|
|
|
|
-- the EC.
|
|
|
|
set enable_mergejoin to off;
|
|
|
|
explain (costs off)
|
|
|
|
select * from ec0 m join ec0 n on m.ff = n.ff
|
|
|
|
join ec1 p on m.ff + n.ff = p.f1;
|
2024-01-23 06:09:18 +01:00
|
|
|
QUERY PLAN
|
|
|
|
---------------------------------------
|
Remove useless self-joins
The Self Join Elimination (SJE) feature removes an inner join of a plain table
to itself in the query tree if is proved that the join can be replaced with
a scan without impacting the query result. Self join and inner relation are
replaced with the outer in query, equivalence classes, and planner info
structures. Also, inner restrictlist moves to the outer one with removing
duplicated clauses. Thus, this optimization reduces the length of the range
table list (this especially makes sense for partitioned relations), reduces
the number of restriction clauses === selectivity estimations, and potentially
can improve total planner prediction for the query.
The SJE proof is based on innerrel_is_unique machinery.
We can remove a self-join when for each outer row:
1. At most one inner row matches the join clause.
2. Each matched inner row must be (physically) the same row as the outer one.
In this patch we use the next approach to identify a self-join:
1. Collect all merge-joinable join quals which look like a.x = b.x
2. Add to the list above the baseretrictinfo of the inner table.
3. Check innerrel_is_unique() for the qual list. If it returns false, skip
this pair of joining tables.
4. Check uniqueness, proved by the baserestrictinfo clauses. To prove
the possibility of self-join elimination inner and outer clauses must have
an exact match.
The relation replacement procedure is not trivial and it is partly combined
with the one, used to remove useless left joins. Tests, covering this feature,
were added to join.sql. Some regression tests changed due to self-join removal
logic.
Discussion: https://postgr.es/m/flat/64486b0b-0404-e39e-322d-0801154901f3%40postgrespro.ru
Author: Andrey Lepikhov, Alexander Kuzmenkov
Reviewed-by: Tom Lane, Robert Haas, Andres Freund, Simon Riggs, Jonathan S. Katz
Reviewed-by: David Rowley, Thomas Munro, Konstantin Knizhnik, Heikki Linnakangas
Reviewed-by: Hywel Carver, Laurenz Albe, Ronan Dunklau, vignesh C, Zhihong Yu
Reviewed-by: Greg Stark, Jaime Casanova, Michał Kłeczek, Alena Rybakina
Reviewed-by: Alexander Korotkov
2023-10-25 11:46:22 +02:00
|
|
|
Nested Loop
|
|
|
|
Join Filter: ((n.ff + n.ff) = p.f1)
|
2024-01-23 06:09:18 +01:00
|
|
|
-> Seq Scan on ec0 n
|
Remove useless self-joins
The Self Join Elimination (SJE) feature removes an inner join of a plain table
to itself in the query tree if is proved that the join can be replaced with
a scan without impacting the query result. Self join and inner relation are
replaced with the outer in query, equivalence classes, and planner info
structures. Also, inner restrictlist moves to the outer one with removing
duplicated clauses. Thus, this optimization reduces the length of the range
table list (this especially makes sense for partitioned relations), reduces
the number of restriction clauses === selectivity estimations, and potentially
can improve total planner prediction for the query.
The SJE proof is based on innerrel_is_unique machinery.
We can remove a self-join when for each outer row:
1. At most one inner row matches the join clause.
2. Each matched inner row must be (physically) the same row as the outer one.
In this patch we use the next approach to identify a self-join:
1. Collect all merge-joinable join quals which look like a.x = b.x
2. Add to the list above the baseretrictinfo of the inner table.
3. Check innerrel_is_unique() for the qual list. If it returns false, skip
this pair of joining tables.
4. Check uniqueness, proved by the baserestrictinfo clauses. To prove
the possibility of self-join elimination inner and outer clauses must have
an exact match.
The relation replacement procedure is not trivial and it is partly combined
with the one, used to remove useless left joins. Tests, covering this feature,
were added to join.sql. Some regression tests changed due to self-join removal
logic.
Discussion: https://postgr.es/m/flat/64486b0b-0404-e39e-322d-0801154901f3%40postgrespro.ru
Author: Andrey Lepikhov, Alexander Kuzmenkov
Reviewed-by: Tom Lane, Robert Haas, Andres Freund, Simon Riggs, Jonathan S. Katz
Reviewed-by: David Rowley, Thomas Munro, Konstantin Knizhnik, Heikki Linnakangas
Reviewed-by: Hywel Carver, Laurenz Albe, Ronan Dunklau, vignesh C, Zhihong Yu
Reviewed-by: Greg Stark, Jaime Casanova, Michał Kłeczek, Alena Rybakina
Reviewed-by: Alexander Korotkov
2023-10-25 11:46:22 +02:00
|
|
|
-> Materialize
|
2024-01-23 06:09:18 +01:00
|
|
|
-> Seq Scan on ec1 p
|
|
|
|
(5 rows)
|
Remove useless self-joins
The Self Join Elimination (SJE) feature removes an inner join of a plain table
to itself in the query tree if is proved that the join can be replaced with
a scan without impacting the query result. Self join and inner relation are
replaced with the outer in query, equivalence classes, and planner info
structures. Also, inner restrictlist moves to the outer one with removing
duplicated clauses. Thus, this optimization reduces the length of the range
table list (this especially makes sense for partitioned relations), reduces
the number of restriction clauses === selectivity estimations, and potentially
can improve total planner prediction for the query.
The SJE proof is based on innerrel_is_unique machinery.
We can remove a self-join when for each outer row:
1. At most one inner row matches the join clause.
2. Each matched inner row must be (physically) the same row as the outer one.
In this patch we use the next approach to identify a self-join:
1. Collect all merge-joinable join quals which look like a.x = b.x
2. Add to the list above the baseretrictinfo of the inner table.
3. Check innerrel_is_unique() for the qual list. If it returns false, skip
this pair of joining tables.
4. Check uniqueness, proved by the baserestrictinfo clauses. To prove
the possibility of self-join elimination inner and outer clauses must have
an exact match.
The relation replacement procedure is not trivial and it is partly combined
with the one, used to remove useless left joins. Tests, covering this feature,
were added to join.sql. Some regression tests changed due to self-join removal
logic.
Discussion: https://postgr.es/m/flat/64486b0b-0404-e39e-322d-0801154901f3%40postgrespro.ru
Author: Andrey Lepikhov, Alexander Kuzmenkov
Reviewed-by: Tom Lane, Robert Haas, Andres Freund, Simon Riggs, Jonathan S. Katz
Reviewed-by: David Rowley, Thomas Munro, Konstantin Knizhnik, Heikki Linnakangas
Reviewed-by: Hywel Carver, Laurenz Albe, Ronan Dunklau, vignesh C, Zhihong Yu
Reviewed-by: Greg Stark, Jaime Casanova, Michał Kłeczek, Alena Rybakina
Reviewed-by: Alexander Korotkov
2023-10-25 11:46:22 +02:00
|
|
|
|
|
|
|
explain (costs off)
|
|
|
|
select * from ec0 m join ec0 n on m.ff = n.ff
|
|
|
|
join ec1 p on p.f1::int8 = (m.ff + n.ff)::int8alias1;
|
|
|
|
QUERY PLAN
|
|
|
|
---------------------------------------------------------------
|
|
|
|
Nested Loop
|
|
|
|
Join Filter: ((p.f1)::bigint = ((n.ff + n.ff))::int8alias1)
|
2024-01-23 06:09:18 +01:00
|
|
|
-> Seq Scan on ec0 n
|
Remove useless self-joins
The Self Join Elimination (SJE) feature removes an inner join of a plain table
to itself in the query tree if is proved that the join can be replaced with
a scan without impacting the query result. Self join and inner relation are
replaced with the outer in query, equivalence classes, and planner info
structures. Also, inner restrictlist moves to the outer one with removing
duplicated clauses. Thus, this optimization reduces the length of the range
table list (this especially makes sense for partitioned relations), reduces
the number of restriction clauses === selectivity estimations, and potentially
can improve total planner prediction for the query.
The SJE proof is based on innerrel_is_unique machinery.
We can remove a self-join when for each outer row:
1. At most one inner row matches the join clause.
2. Each matched inner row must be (physically) the same row as the outer one.
In this patch we use the next approach to identify a self-join:
1. Collect all merge-joinable join quals which look like a.x = b.x
2. Add to the list above the baseretrictinfo of the inner table.
3. Check innerrel_is_unique() for the qual list. If it returns false, skip
this pair of joining tables.
4. Check uniqueness, proved by the baserestrictinfo clauses. To prove
the possibility of self-join elimination inner and outer clauses must have
an exact match.
The relation replacement procedure is not trivial and it is partly combined
with the one, used to remove useless left joins. Tests, covering this feature,
were added to join.sql. Some regression tests changed due to self-join removal
logic.
Discussion: https://postgr.es/m/flat/64486b0b-0404-e39e-322d-0801154901f3%40postgrespro.ru
Author: Andrey Lepikhov, Alexander Kuzmenkov
Reviewed-by: Tom Lane, Robert Haas, Andres Freund, Simon Riggs, Jonathan S. Katz
Reviewed-by: David Rowley, Thomas Munro, Konstantin Knizhnik, Heikki Linnakangas
Reviewed-by: Hywel Carver, Laurenz Albe, Ronan Dunklau, vignesh C, Zhihong Yu
Reviewed-by: Greg Stark, Jaime Casanova, Michał Kłeczek, Alena Rybakina
Reviewed-by: Alexander Korotkov
2023-10-25 11:46:22 +02:00
|
|
|
-> Materialize
|
2024-01-23 06:09:18 +01:00
|
|
|
-> Seq Scan on ec1 p
|
|
|
|
(5 rows)
|
Remove useless self-joins
The Self Join Elimination (SJE) feature removes an inner join of a plain table
to itself in the query tree if is proved that the join can be replaced with
a scan without impacting the query result. Self join and inner relation are
replaced with the outer in query, equivalence classes, and planner info
structures. Also, inner restrictlist moves to the outer one with removing
duplicated clauses. Thus, this optimization reduces the length of the range
table list (this especially makes sense for partitioned relations), reduces
the number of restriction clauses === selectivity estimations, and potentially
can improve total planner prediction for the query.
The SJE proof is based on innerrel_is_unique machinery.
We can remove a self-join when for each outer row:
1. At most one inner row matches the join clause.
2. Each matched inner row must be (physically) the same row as the outer one.
In this patch we use the next approach to identify a self-join:
1. Collect all merge-joinable join quals which look like a.x = b.x
2. Add to the list above the baseretrictinfo of the inner table.
3. Check innerrel_is_unique() for the qual list. If it returns false, skip
this pair of joining tables.
4. Check uniqueness, proved by the baserestrictinfo clauses. To prove
the possibility of self-join elimination inner and outer clauses must have
an exact match.
The relation replacement procedure is not trivial and it is partly combined
with the one, used to remove useless left joins. Tests, covering this feature,
were added to join.sql. Some regression tests changed due to self-join removal
logic.
Discussion: https://postgr.es/m/flat/64486b0b-0404-e39e-322d-0801154901f3%40postgrespro.ru
Author: Andrey Lepikhov, Alexander Kuzmenkov
Reviewed-by: Tom Lane, Robert Haas, Andres Freund, Simon Riggs, Jonathan S. Katz
Reviewed-by: David Rowley, Thomas Munro, Konstantin Knizhnik, Heikki Linnakangas
Reviewed-by: Hywel Carver, Laurenz Albe, Ronan Dunklau, vignesh C, Zhihong Yu
Reviewed-by: Greg Stark, Jaime Casanova, Michał Kłeczek, Alena Rybakina
Reviewed-by: Alexander Korotkov
2023-10-25 11:46:22 +02:00
|
|
|
|
|
|
|
reset enable_mergejoin;
|
Reduce "X = X" to "X IS NOT NULL", if it's easy to do so.
If the operator is a strict btree equality operator, and X isn't volatile,
then the clause must yield true for any non-null value of X, or null if X
is null. At top level of a WHERE clause, we can ignore the distinction
between false and null results, so it's valid to simplify the clause to
"X IS NOT NULL". This is a useful improvement mainly because we'll get
a far better selectivity estimate in most cases.
Because such cases seldom arise in well-written queries, it is unappetizing
to expend a lot of planner cycles looking for them ... but it turns out
that there's a place we can shoehorn this in practically for free, because
equivclass.c already has to detect and reject candidate equivalences of the
form X = X. That doesn't catch every place that it would be valid to
simplify to X IS NOT NULL, but it catches the typical case. Working harder
doesn't seem justified.
Patch by me, reviewed by Petr Jelinek
Discussion: https://postgr.es/m/CAMjNa7cC4X9YR-vAJS-jSYCajhRDvJQnN7m2sLH1wLh-_Z2bsw@mail.gmail.com
2017-10-08 18:23:32 +02:00
|
|
|
-- this could be converted, but isn't at present
|
|
|
|
explain (costs off)
|
|
|
|
select * from tenk1 where unique1 = unique1 or unique2 = unique2;
|
|
|
|
QUERY PLAN
|
|
|
|
--------------------------------------------------------
|
|
|
|
Seq Scan on tenk1
|
|
|
|
Filter: ((unique1 = unique1) OR (unique2 = unique2))
|
|
|
|
(2 rows)
|
|
|
|
|
2020-02-27 00:13:58 +01:00
|
|
|
-- check that we recognize equivalence with dummy domains in the way
|
|
|
|
create temp table undername (f1 name, f2 int);
|
|
|
|
create temp view overview as
|
|
|
|
select f1::information_schema.sql_identifier as sqli, f2 from undername;
|
|
|
|
explain (costs off) -- this should not require a sort
|
|
|
|
select * from overview where sqli = 'foo' order by sqli;
|
|
|
|
QUERY PLAN
|
|
|
|
------------------------------
|
|
|
|
Seq Scan on undername
|
|
|
|
Filter: (f1 = 'foo'::name)
|
|
|
|
(2 rows)
|
|
|
|
|