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
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
Zeyuan Hu writes:
> In https://github.com/postgres/postgres/tree/master/src/backend/optimizer,
> there are two examples on the dynamic programming (DP) algorithm used in
> the optimizer, which I think
> have some inaccuracy:
You're right that these examples do not consider the effects of
clauses
Hello,
In https://github.com/postgres/postgres/tree/master/src/backend/optimizer,
there are two examples on the dynamic programming (DP) algorithm used in
the optimizer, which I think
have some inaccuracy:
SELECT *
FROMtab1, tab2, tab3, tab4
WHERE tab1.col = tab2.col AND
ta
