Doc: note that two examples in optimizer/README are oversimplified.

These examples fail to account for join clauses generated by
EquivalenceClasses, but since we haven't mentioned EquivalenceClasses
yet it seems like it'd just add confusion to make them fully accurate.
Instead, parenthetically note that they're oversimplified.

Reported-by: Zeyuan Hu <[email protected]>
Co-authored-by: David Rowley <[email protected]>
Co-authored-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/CACvHWmYFo+60yMqKJajDDvKN5EM41YHrCT3oxukwXmGAqpWvyw@mail.gmail.com

1 files changed, 5 insertions, 1 deletions

diff --git a/src/backend/optimizer/README b/src/backend/optimizer/README
index f341d9f303c..21c2db5a85c 100644
--- a/src/backend/optimizer/README
+++ b/src/backend/optimizer/README
@@ -143,7 +143,6 @@ For example:
     {1 2},{2 3},{3 4}
     {1 2 3},{2 3 4}
     {1 2 3 4}
-    (other possibilities will be excluded for lack of join clauses)
 
     SELECT  *
     FROM    tab1, tab2, tab3, tab4
@@ -156,6 +155,11 @@ For example:
     {1 2 3},{1 3 4},{1 2 4}
     {1 2 3 4}
 
+In each of these examples, other join-order possibilities will be excluded
+for lack of join clauses.  (In reality, use of EquivalenceClasses would
+allow us to deduce additional join clauses that allow more join orders,
+but here we ignore that to preserve the simplicity of the examples.)
+
 We consider left-handed plans (the outer rel of an upper join is a joinrel,
 but the inner is always a single list item); right-handed plans (outer rel
 is always a single item); and bushy plans (both inner and outer can be