1996-07-09 08:22:35 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
1999-02-14 00:22:53 +01:00
|
|
|
* joininfo.c
|
2005-06-09 06:19:00 +02:00
|
|
|
* joininfo list manipulation routines
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
2024-01-04 02:49:05 +01:00
|
|
|
* Portions Copyright (c) 1996-2024, PostgreSQL Global Development Group
|
2000-01-26 06:58:53 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
*
|
|
|
|
* IDENTIFICATION
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/backend/optimizer/util/joininfo.c
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
#include "postgres.h"
|
|
|
|
|
2024-01-23 06:09:18 +01:00
|
|
|
#include "nodes/makefuncs.h"
|
1999-07-16 07:00:38 +02:00
|
|
|
#include "optimizer/joininfo.h"
|
2003-01-24 04:58:44 +01:00
|
|
|
#include "optimizer/pathnode.h"
|
2007-01-20 21:45:41 +01:00
|
|
|
#include "optimizer/paths.h"
|
2024-01-23 06:09:18 +01:00
|
|
|
#include "optimizer/planmain.h"
|
|
|
|
#include "optimizer/restrictinfo.h"
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
/*
|
2005-06-09 06:19:00 +02:00
|
|
|
* have_relevant_joinclause
|
2012-04-13 21:32:34 +02:00
|
|
|
* Detect whether there is a joinclause that involves
|
2005-06-09 06:19:00 +02:00
|
|
|
* the two given relations.
|
2012-04-13 21:32:34 +02:00
|
|
|
*
|
2017-02-06 10:33:58 +01:00
|
|
|
* Note: the joinclause does not have to be evaluable with only these two
|
2012-04-13 21:32:34 +02:00
|
|
|
* relations. This is intentional. For example consider
|
|
|
|
* SELECT * FROM a, b, c WHERE a.x = (b.y + c.z)
|
|
|
|
* If a is much larger than the other tables, it may be worthwhile to
|
|
|
|
* cross-join b and c and then use an inner indexscan on a.x. Therefore
|
|
|
|
* we should consider this joinclause as reason to join b to c, even though
|
|
|
|
* it can't be applied at that join step.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2005-06-09 06:19:00 +02:00
|
|
|
bool
|
2006-12-12 22:31:02 +01:00
|
|
|
have_relevant_joinclause(PlannerInfo *root,
|
|
|
|
RelOptInfo *rel1, RelOptInfo *rel2)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2005-06-09 06:19:00 +02:00
|
|
|
bool result = false;
|
|
|
|
List *joininfo;
|
2012-04-13 21:32:34 +02:00
|
|
|
Relids other_relids;
|
2004-05-26 06:41:50 +02:00
|
|
|
ListCell *l;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2005-06-09 06:19:00 +02:00
|
|
|
/*
|
|
|
|
* We could scan either relation's joininfo list; may as well use the
|
|
|
|
* shorter one.
|
|
|
|
*/
|
|
|
|
if (list_length(rel1->joininfo) <= list_length(rel2->joininfo))
|
2012-04-13 21:32:34 +02:00
|
|
|
{
|
2005-06-09 06:19:00 +02:00
|
|
|
joininfo = rel1->joininfo;
|
2012-04-13 21:32:34 +02:00
|
|
|
other_relids = rel2->relids;
|
|
|
|
}
|
2005-06-09 06:19:00 +02:00
|
|
|
else
|
2012-04-13 21:32:34 +02:00
|
|
|
{
|
2005-06-09 06:19:00 +02:00
|
|
|
joininfo = rel2->joininfo;
|
2012-04-13 21:32:34 +02:00
|
|
|
other_relids = rel1->relids;
|
|
|
|
}
|
2005-06-09 06:19:00 +02:00
|
|
|
|
|
|
|
foreach(l, joininfo)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2005-06-09 06:19:00 +02:00
|
|
|
RestrictInfo *rinfo = (RestrictInfo *) lfirst(l);
|
1999-02-18 01:49:48 +01:00
|
|
|
|
2012-04-13 21:32:34 +02:00
|
|
|
if (bms_overlap(other_relids, rinfo->required_relids))
|
2005-06-09 06:19:00 +02:00
|
|
|
{
|
|
|
|
result = true;
|
|
|
|
break;
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2007-01-20 21:45:41 +01:00
|
|
|
/*
|
|
|
|
* We also need to check the EquivalenceClass data structure, which might
|
|
|
|
* contain relationships not emitted into the joininfo lists.
|
|
|
|
*/
|
|
|
|
if (!result && rel1->has_eclass_joins && rel2->has_eclass_joins)
|
|
|
|
result = have_relevant_eclass_joinclause(root, rel1, rel2);
|
|
|
|
|
2005-06-09 06:19:00 +02:00
|
|
|
return result;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
2003-01-24 04:58:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* add_join_clause_to_rels
|
2005-06-09 06:19:00 +02:00
|
|
|
* Add 'restrictinfo' to the joininfo list of each relation it requires.
|
2003-01-24 04:58:44 +01:00
|
|
|
*
|
|
|
|
* Note that the same copy of the restrictinfo node is linked to by all the
|
|
|
|
* lists it is in. This allows us to exploit caching of information about
|
|
|
|
* the restriction clause (but we must be careful that the information does
|
|
|
|
* not depend on context).
|
|
|
|
*
|
|
|
|
* 'restrictinfo' describes the join clause
|
Make Vars be outer-join-aware.
Traditionally we used the same Var struct to represent the value
of a table column everywhere in parse and plan trees. This choice
predates our support for SQL outer joins, and it's really a pretty
bad idea with outer joins, because the Var's value can depend on
where it is in the tree: it might go to NULL above an outer join.
So expression nodes that are equal() per equalfuncs.c might not
represent the same value, which is a huge correctness hazard for
the planner.
To improve this, decorate Var nodes with a bitmapset showing
which outer joins (identified by RTE indexes) may have nulled
them at the point in the parse tree where the Var appears.
This allows us to trust that equal() Vars represent the same value.
A certain amount of klugery is still needed to cope with cases
where we re-order two outer joins, but it's possible to make it
work without sacrificing that core principle. PlaceHolderVars
receive similar decoration for the same reason.
In the planner, we include these outer join bitmapsets into the relids
that an expression is considered to depend on, and in consequence also
add outer-join relids to the relids of join RelOptInfos. This allows
us to correctly perceive whether an expression can be calculated above
or below a particular outer join.
This change affects FDWs that want to plan foreign joins. They *must*
follow suit when labeling foreign joins in order to match with the
core planner, but for many purposes (if postgres_fdw is any guide)
they'd prefer to consider only base relations within the join.
To support both requirements, redefine ForeignScan.fs_relids as
base+OJ relids, and add a new field fs_base_relids that's set up by
the core planner.
Large though it is, this commit just does the minimum necessary to
install the new mechanisms and get check-world passing again.
Follow-up patches will perform some cleanup. (The README additions
and comments mention some stuff that will appear in the follow-up.)
Patch by me; thanks to Richard Guo for review.
Discussion: https://postgr.es/m/830269.1656693747@sss.pgh.pa.us
2023-01-30 19:16:20 +01:00
|
|
|
* 'join_relids' is the set of relations participating in the join clause
|
|
|
|
* (some of these could be outer joins)
|
2003-01-24 04:58:44 +01:00
|
|
|
*/
|
|
|
|
void
|
2005-06-06 00:32:58 +02:00
|
|
|
add_join_clause_to_rels(PlannerInfo *root,
|
2003-01-24 04:58:44 +01:00
|
|
|
RestrictInfo *restrictinfo,
|
|
|
|
Relids join_relids)
|
|
|
|
{
|
2003-02-08 21:20:55 +01:00
|
|
|
int cur_relid;
|
2003-01-24 04:58:44 +01:00
|
|
|
|
2024-01-23 06:09:18 +01:00
|
|
|
/* Don't add the clause if it is always true */
|
|
|
|
if (restriction_is_always_true(root, restrictinfo))
|
|
|
|
return;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Substitute constant-FALSE for the origin qual if it is always false.
|
|
|
|
* Note that we keep the same rinfo_serial.
|
|
|
|
*/
|
|
|
|
if (restriction_is_always_false(root, restrictinfo))
|
|
|
|
{
|
|
|
|
int save_rinfo_serial = restrictinfo->rinfo_serial;
|
|
|
|
|
|
|
|
restrictinfo = make_restrictinfo(root,
|
|
|
|
(Expr *) makeBoolConst(false, false),
|
|
|
|
restrictinfo->is_pushed_down,
|
|
|
|
restrictinfo->has_clone,
|
|
|
|
restrictinfo->is_clone,
|
|
|
|
restrictinfo->pseudoconstant,
|
|
|
|
0, /* security_level */
|
|
|
|
restrictinfo->required_relids,
|
|
|
|
restrictinfo->incompatible_relids,
|
|
|
|
restrictinfo->outer_relids);
|
|
|
|
restrictinfo->rinfo_serial = save_rinfo_serial;
|
|
|
|
}
|
|
|
|
|
2014-11-28 19:37:25 +01:00
|
|
|
cur_relid = -1;
|
|
|
|
while ((cur_relid = bms_next_member(join_relids, cur_relid)) >= 0)
|
2003-01-24 04:58:44 +01:00
|
|
|
{
|
Make Vars be outer-join-aware.
Traditionally we used the same Var struct to represent the value
of a table column everywhere in parse and plan trees. This choice
predates our support for SQL outer joins, and it's really a pretty
bad idea with outer joins, because the Var's value can depend on
where it is in the tree: it might go to NULL above an outer join.
So expression nodes that are equal() per equalfuncs.c might not
represent the same value, which is a huge correctness hazard for
the planner.
To improve this, decorate Var nodes with a bitmapset showing
which outer joins (identified by RTE indexes) may have nulled
them at the point in the parse tree where the Var appears.
This allows us to trust that equal() Vars represent the same value.
A certain amount of klugery is still needed to cope with cases
where we re-order two outer joins, but it's possible to make it
work without sacrificing that core principle. PlaceHolderVars
receive similar decoration for the same reason.
In the planner, we include these outer join bitmapsets into the relids
that an expression is considered to depend on, and in consequence also
add outer-join relids to the relids of join RelOptInfos. This allows
us to correctly perceive whether an expression can be calculated above
or below a particular outer join.
This change affects FDWs that want to plan foreign joins. They *must*
follow suit when labeling foreign joins in order to match with the
core planner, but for many purposes (if postgres_fdw is any guide)
they'd prefer to consider only base relations within the join.
To support both requirements, redefine ForeignScan.fs_relids as
base+OJ relids, and add a new field fs_base_relids that's set up by
the core planner.
Large though it is, this commit just does the minimum necessary to
install the new mechanisms and get check-world passing again.
Follow-up patches will perform some cleanup. (The README additions
and comments mention some stuff that will appear in the follow-up.)
Patch by me; thanks to Richard Guo for review.
Discussion: https://postgr.es/m/830269.1656693747@sss.pgh.pa.us
2023-01-30 19:16:20 +01:00
|
|
|
RelOptInfo *rel = find_base_rel_ignore_join(root, cur_relid);
|
2003-01-24 04:58:44 +01:00
|
|
|
|
Make Vars be outer-join-aware.
Traditionally we used the same Var struct to represent the value
of a table column everywhere in parse and plan trees. This choice
predates our support for SQL outer joins, and it's really a pretty
bad idea with outer joins, because the Var's value can depend on
where it is in the tree: it might go to NULL above an outer join.
So expression nodes that are equal() per equalfuncs.c might not
represent the same value, which is a huge correctness hazard for
the planner.
To improve this, decorate Var nodes with a bitmapset showing
which outer joins (identified by RTE indexes) may have nulled
them at the point in the parse tree where the Var appears.
This allows us to trust that equal() Vars represent the same value.
A certain amount of klugery is still needed to cope with cases
where we re-order two outer joins, but it's possible to make it
work without sacrificing that core principle. PlaceHolderVars
receive similar decoration for the same reason.
In the planner, we include these outer join bitmapsets into the relids
that an expression is considered to depend on, and in consequence also
add outer-join relids to the relids of join RelOptInfos. This allows
us to correctly perceive whether an expression can be calculated above
or below a particular outer join.
This change affects FDWs that want to plan foreign joins. They *must*
follow suit when labeling foreign joins in order to match with the
core planner, but for many purposes (if postgres_fdw is any guide)
they'd prefer to consider only base relations within the join.
To support both requirements, redefine ForeignScan.fs_relids as
base+OJ relids, and add a new field fs_base_relids that's set up by
the core planner.
Large though it is, this commit just does the minimum necessary to
install the new mechanisms and get check-world passing again.
Follow-up patches will perform some cleanup. (The README additions
and comments mention some stuff that will appear in the follow-up.)
Patch by me; thanks to Richard Guo for review.
Discussion: https://postgr.es/m/830269.1656693747@sss.pgh.pa.us
2023-01-30 19:16:20 +01:00
|
|
|
/* We only need to add the clause to baserels */
|
|
|
|
if (rel == NULL)
|
|
|
|
continue;
|
2005-06-09 06:19:00 +02:00
|
|
|
rel->joininfo = lappend(rel->joininfo, restrictinfo);
|
2003-01-24 04:58:44 +01:00
|
|
|
}
|
|
|
|
}
|
2010-09-15 01:15:29 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* remove_join_clause_from_rels
|
|
|
|
* Delete 'restrictinfo' from all the joininfo lists it is in
|
|
|
|
*
|
|
|
|
* This reverses the effect of add_join_clause_to_rels. It's used when we
|
|
|
|
* discover that a relation need not be joined at all.
|
|
|
|
*
|
|
|
|
* 'restrictinfo' describes the join clause
|
Make Vars be outer-join-aware.
Traditionally we used the same Var struct to represent the value
of a table column everywhere in parse and plan trees. This choice
predates our support for SQL outer joins, and it's really a pretty
bad idea with outer joins, because the Var's value can depend on
where it is in the tree: it might go to NULL above an outer join.
So expression nodes that are equal() per equalfuncs.c might not
represent the same value, which is a huge correctness hazard for
the planner.
To improve this, decorate Var nodes with a bitmapset showing
which outer joins (identified by RTE indexes) may have nulled
them at the point in the parse tree where the Var appears.
This allows us to trust that equal() Vars represent the same value.
A certain amount of klugery is still needed to cope with cases
where we re-order two outer joins, but it's possible to make it
work without sacrificing that core principle. PlaceHolderVars
receive similar decoration for the same reason.
In the planner, we include these outer join bitmapsets into the relids
that an expression is considered to depend on, and in consequence also
add outer-join relids to the relids of join RelOptInfos. This allows
us to correctly perceive whether an expression can be calculated above
or below a particular outer join.
This change affects FDWs that want to plan foreign joins. They *must*
follow suit when labeling foreign joins in order to match with the
core planner, but for many purposes (if postgres_fdw is any guide)
they'd prefer to consider only base relations within the join.
To support both requirements, redefine ForeignScan.fs_relids as
base+OJ relids, and add a new field fs_base_relids that's set up by
the core planner.
Large though it is, this commit just does the minimum necessary to
install the new mechanisms and get check-world passing again.
Follow-up patches will perform some cleanup. (The README additions
and comments mention some stuff that will appear in the follow-up.)
Patch by me; thanks to Richard Guo for review.
Discussion: https://postgr.es/m/830269.1656693747@sss.pgh.pa.us
2023-01-30 19:16:20 +01:00
|
|
|
* 'join_relids' is the set of relations participating in the join clause
|
|
|
|
* (some of these could be outer joins)
|
2010-09-15 01:15:29 +02:00
|
|
|
*/
|
|
|
|
void
|
|
|
|
remove_join_clause_from_rels(PlannerInfo *root,
|
|
|
|
RestrictInfo *restrictinfo,
|
|
|
|
Relids join_relids)
|
|
|
|
{
|
|
|
|
int cur_relid;
|
|
|
|
|
2014-11-28 19:37:25 +01:00
|
|
|
cur_relid = -1;
|
|
|
|
while ((cur_relid = bms_next_member(join_relids, cur_relid)) >= 0)
|
2010-09-15 01:15:29 +02:00
|
|
|
{
|
Make Vars be outer-join-aware.
Traditionally we used the same Var struct to represent the value
of a table column everywhere in parse and plan trees. This choice
predates our support for SQL outer joins, and it's really a pretty
bad idea with outer joins, because the Var's value can depend on
where it is in the tree: it might go to NULL above an outer join.
So expression nodes that are equal() per equalfuncs.c might not
represent the same value, which is a huge correctness hazard for
the planner.
To improve this, decorate Var nodes with a bitmapset showing
which outer joins (identified by RTE indexes) may have nulled
them at the point in the parse tree where the Var appears.
This allows us to trust that equal() Vars represent the same value.
A certain amount of klugery is still needed to cope with cases
where we re-order two outer joins, but it's possible to make it
work without sacrificing that core principle. PlaceHolderVars
receive similar decoration for the same reason.
In the planner, we include these outer join bitmapsets into the relids
that an expression is considered to depend on, and in consequence also
add outer-join relids to the relids of join RelOptInfos. This allows
us to correctly perceive whether an expression can be calculated above
or below a particular outer join.
This change affects FDWs that want to plan foreign joins. They *must*
follow suit when labeling foreign joins in order to match with the
core planner, but for many purposes (if postgres_fdw is any guide)
they'd prefer to consider only base relations within the join.
To support both requirements, redefine ForeignScan.fs_relids as
base+OJ relids, and add a new field fs_base_relids that's set up by
the core planner.
Large though it is, this commit just does the minimum necessary to
install the new mechanisms and get check-world passing again.
Follow-up patches will perform some cleanup. (The README additions
and comments mention some stuff that will appear in the follow-up.)
Patch by me; thanks to Richard Guo for review.
Discussion: https://postgr.es/m/830269.1656693747@sss.pgh.pa.us
2023-01-30 19:16:20 +01:00
|
|
|
RelOptInfo *rel = find_base_rel_ignore_join(root, cur_relid);
|
|
|
|
|
|
|
|
/* We would only have added the clause to baserels */
|
|
|
|
if (rel == NULL)
|
|
|
|
continue;
|
2010-09-15 01:15:29 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Remove the restrictinfo from the list. Pointer comparison is
|
|
|
|
* sufficient.
|
|
|
|
*/
|
|
|
|
Assert(list_member_ptr(rel->joininfo, restrictinfo));
|
|
|
|
rel->joininfo = list_delete_ptr(rel->joininfo, restrictinfo);
|
|
|
|
}
|
|
|
|
}
|