aboutsummaryrefslogtreecommitdiff
path: root/src/backend/optimizer/README
diff options
context:
space:
mode:
Diffstat (limited to 'src/backend/optimizer/README')
-rw-r--r--src/backend/optimizer/README34
1 files changed, 27 insertions, 7 deletions
diff --git a/src/backend/optimizer/README b/src/backend/optimizer/README
index adaa07ee60e..2af4231089b 100644
--- a/src/backend/optimizer/README
+++ b/src/backend/optimizer/README
@@ -705,17 +705,37 @@ intermediate layers of joins, for example:
-> Index Scan using C_Z_IDX on C
Index Condition: C.Z = A.X
-If all joins are plain inner joins then this is unnecessary, because
-it's always possible to reorder the joins so that a parameter is used
+If all joins are plain inner joins then this is usually unnecessary,
+because it's possible to reorder the joins so that a parameter is used
immediately below the nestloop node that provides it. But in the
-presence of outer joins, join reordering may not be possible, and then
-this option can be critical. Before version 9.2, Postgres used ad-hoc
-methods for planning and executing such queries, and those methods could
-not handle passing parameters down through multiple join levels.
+presence of outer joins, such join reordering may not be possible.
+
+Also, the bottom-level scan might require parameters from more than one
+other relation. In principle we could join the other relations first
+so that all the parameters are supplied from a single nestloop level.
+But if those other relations have no join clause in common (which is
+common in star-schema queries for instance), the planner won't consider
+joining them directly to each other. In such a case we need to be able
+to create a plan like
+
+ NestLoop
+ -> Seq Scan on SmallTable1 A
+ NestLoop
+ -> Seq Scan on SmallTable2 B
+ NestLoop
+ -> Index Scan using XYIndex on LargeTable C
+ Index Condition: C.X = A.AID and C.Y = B.BID
+
+so we should be willing to pass down A.AID through a join even though
+there is no join order constraint forcing the plan to look like this.
+
+Before version 9.2, Postgres used ad-hoc methods for planning and
+executing nestloop queries of this kind, and those methods could not
+handle passing parameters down through multiple join levels.
To plan such queries, we now use a notion of a "parameterized path",
which is a path that makes use of a join clause to a relation that's not
-scanned by the path. In the example just above, we would construct a
+scanned by the path. In the example two above, we would construct a
path representing the possibility of doing this:
-> Index Scan using C_Z_IDX on C