database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-15 19:21:59 +03:00
Code Activity

More fixes for planner's handling of LATERAL.

Browse Source 
Re-allow subquery pullup for LATERAL subqueries, except when the subquery
is below an outer join and contains lateral references to relations outside
that outer join.  If we pull up in such a case, we risk introducing lateral
cross-references into outer joins' ON quals, which is something the code is
entirely unprepared to cope with right now; and I'm not sure it'll ever be
worth coping with.

Support lateral refs in VALUES (this seems to be the only additional path
type that needs such support as a consequence of re-allowing subquery
pullup).

Put in a slightly hacky fix for joinpath.c's refusal to consider
parameterized join paths even when there cannot be any unparameterized
ones.  This was causing "could not devise a query plan for the given query"
failures in queries involving more than two FROM items.

Put in an even more hacky fix for distribute_qual_to_rels() being unhappy
with join quals that contain references to rels outside their syntactic
scope; which is to say, disable that test altogether.  Need to think about
how to preserve some sort of debugging cross-check here, while not
expending more cycles than befits a debugging cross-check.
This commit is contained in:
Tom Lane
2012-08-12 16:01:26 -04:00
parent e76af54137
commit c1774d2c81
13 changed files with 390 additions and 89 deletions
Download Patch File Download Diff File Expand all files Collapse all files

26
src/backend/optimizer/path/allpaths.c
View File

@ -1210,15 +1210,33 @@ set_function_pathlist(PlannerInfo *root, RelOptInfo *rel, RangeTblEntry *rte)
* set_values_pathlist
* Build the (single) access path for a VALUES RTE
*
* There can be no need for a parameterized path here. (Although the SQL
* spec does allow LATERAL (VALUES (x)), the parser will transform that
* into a subquery, so it doesn't end up here.)
* As with subqueries, a VALUES RTE's path might be parameterized due to
* LATERAL references, but that's inherent in the values expressions and
* not a result of pushing down join quals.
*/
static void
set_values_pathlist(PlannerInfo *root, RelOptInfo *rel, RangeTblEntry *rte)
{
Relids required_outer;
/*
* If it's a LATERAL RTE, it might contain some Vars of the current query
* level, requiring it to be treated as parameterized. (NB: even though
* the parser never marks VALUES RTEs as LATERAL, they could be so marked
* by now, as a result of subquery pullup.)
*/
if (rte->lateral)
{
required_outer = pull_varnos_of_level((Node *) rte->values_lists, 0);
/* Enforce convention that empty required_outer is exactly NULL */
if (bms_is_empty(required_outer))
required_outer = NULL;
}
else
required_outer = NULL;
/* Generate appropriate path */
add_path(rel, create_valuesscan_path(root, rel));
add_path(rel, create_valuesscan_path(root, rel, required_outer));
/* Select cheapest path (pretty easy in this case...) */
set_cheapest(rel);