From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Zeyuan Hu <ferrishu3886(at)gmail(dot)com>, pgsql-docs(at)postgresql(dot)org |
Subject: | Re: Possible documentation inaccuracy in optimizer README |
Date: | 2025-04-09 01:24:29 |
Message-ID: | CAApHDvpbJrzQC-gZk0XpxMbk5CW=zj+R5KajuhP=Hw7xSdL5VQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs |
On Tue, 8 Apr 2025 at 16:28, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2025-04-09 02:33:52 | Re: Possible documentation inaccuracy in optimizer README |
Previous Message | PG Doc comments form | 2025-04-08 21:21:06 | Missing "each" in `NegotiateProtocolVersion` protocol message format description |