On 1/3/2022 03:03, Greg Stark wrote:
> On Thu, 1 Jul 2021 at 02:38, Ronan Dunklau <ronan.dunklau@aiven.io> wrote:
>>
>> Well in some cases they can't, when the query is not emitting redundant
>> predicates by itself but they are added by something else like a view or a RLS
>> policy.
>> Maybe it would be worth it to allow spending a bit more time planning for
>> those cases ?
>
> Yeah, I'm generally in favour of doing more work in the optimizer to
> save query authors work writing queries.
>
> My question is whether it handles cases like:
>
> select b.x,c.y
> from t
> join t2 as b on (b.id = t.id)
> join t2 as c on (c.id = t.id)
>
> That is, if you join against the same table twice on the same qual.
> Does the EC mechanism turn this into a qual on b.id = c.id and then
> turn this into a self-join that can be removed?
Yes, the self-join removal machinery uses EC mechanism as usual to get
all join clauses. So, this case works (See demo in attachment).
Also, in new version of the patch I fixed one stupid bug: checking a
self-join candidate expression operator - we can remove only expressions
like F(arg1) = G(arg2).
--
regards,
Andrey Lepikhov
Postgres Professional
