David Rowley writes:
> On Wed, 9 Apr 2025 at 14:33, Tom Lane wrote:
>> 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 w
David Rowley 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 claus
On Tue, 8 Apr 2025 at 16:28, Tom Lane 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
Hello Tom,
Thanks for the clarification. I now understand the main goal of the
examples. I was confused by the remarks in the example "(other
possibilities will be excluded for lack of join clauses)" as this is not a
true statement: some possibilities are not shown for lack of join clauses
while o
You do not provide the output of the table description, but write that the
system generated the name $2
> 7 квіт. 2025 р. о 16:34 David G. Johnston пише:
>
> On Sunday, April 6, 2025, PG Doc comments form
> wrote:
>> The following documentation comment has been logged on the website:
>>
>>
