Re: Possible documentation inaccuracy in optimizer README - Mailing list pgsql-docs

From David Rowley
Subject Re: Possible documentation inaccuracy in optimizer README
Date
Msg-id CAApHDvpbJrzQC-gZk0XpxMbk5CW=zj+R5KajuhP=Hw7xSdL5VQ@mail.gmail.com
Whole thread Raw
In response to Re: Possible documentation inaccuracy in optimizer README  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Possible documentation inaccuracy in optimizer README
List pgsql-docs
On Tue, 8 Apr 2025 at 16:28, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> We could possibly avoid the inaccuracy by making the examples use
> some other operators that are not equijoins.  But I wonder if that
> would not be more confusing rather than less so.

I don't think it'd hurt to mention that we're just ignoring the
existence of ECs for this example. Something like:

--- a/src/backend/optimizer/README
+++ b/src/backend/optimizer/README
@@ -143,7 +143,10 @@ 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)
+    (other possibilities will be excluded for lack of join clauses
+    (technically, EquivalenceClasses do allow us to determine derived join
+    clauses for this case, but we ignore that for the simplicity of this
+    example))

     SELECT  *
     FROM    tab1, tab2, tab3, tab4

If it'll stop a future question or someone from being confused, it
seems worthwhile.

David



pgsql-docs by date:

Previous
From: PG Doc comments form
Date:
Subject: Missing "each" in `NegotiateProtocolVersion` protocol message format description
Next
From: Tom Lane
Date:
Subject: Re: Possible documentation inaccuracy in optimizer README