From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Rowley <dgrowleyml@gmail.com>
cc: Zeyuan Hu <ferrishu3886@gmail.com>, pgsql-docs@postgresql.org
Subject: Re: Possible documentation inaccuracy in optimizer README
In-reply-to: 
 <CAApHDvpbJrzQC-gZk0XpxMbk5CW=zj+R5KajuhP=Hw7xSdL5VQ@mail.gmail.com>
References: 
 <CACvHWmYFo+60yMqKJajDDvKN5EM41YHrCT3oxukwXmGAqpWvyw@mail.gmail.com>
 <3887651.1744086487@sss.pgh.pa.us>
 <CAApHDvpbJrzQC-gZk0XpxMbk5CW=zj+R5KajuhP=Hw7xSdL5VQ@mail.gmail.com>
Comments: In-reply-to David Rowley <dgrowleyml@gmail.com>
	message dated "Wed, 09 Apr 2025 13:24:29 +1200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <111827.1744166032.1@sss.pgh.pa.us>
Date: Tue, 08 Apr 2025 22:33:52 -0400
Message-ID: <111828.1744166032@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/111828.1744166032%40sss.pgh.pa.us>
Precedence: bulk

David Rowley <dgrowleyml@gmail.com> writes:
> I don't think it'd hurt to mention that we're just ignoring the
> existence of ECs for this example.

Seems like a reasonable approach.

> -    (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))

Maybe better:

	Other 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
	combinations, but here we ignore that to preserve the
	simplicity of this example.)

			regards, tom lane