|From:||Andrey Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru>|
|To:||Greg Stark <stark(at)mit(dot)edu>, Ronan Dunklau <ronan(dot)dunklau(at)aiven(dot)io>|
|Cc:||Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Hywel Carver <hywel(at)skillerwhale(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Konstantin Knizhnik <knizhnik(at)garret(dot)ru>|
|Subject:||Re: Removing unneeded self joins|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 1/3/2022 03:03, Greg Stark wrote:
> On Thu, 1 Jul 2021 at 02:38, Ronan Dunklau <ronan(dot)dunklau(at)aiven(dot)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
>> 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).
|Next Message||Thomas Munro||2022-03-04 10:50:46||Re: Regression tests failures on Windows Server 2019 - on master at commit # d816f366b|
|Previous Message||Amit Kapila||2022-03-04 10:42:30||Re: Column Filtering in Logical Replication|