From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Richard Guo <guofenglinux(at)gmail(dot)com> |
Cc: | Andrei Lepikhov <lepihov(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Memoize ANTI and SEMI JOIN inner |
Date: | 2025-04-09 09:18:25 |
Message-ID: | CAApHDvqcuPQoSR+LPtpDOT5vVWj0LS0d0ZaqfJ1U3d+c4ieTdA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 9 Apr 2025 at 18:48, Richard Guo <guofenglinux(at)gmail(dot)com> wrote:
>
> On Thu, Mar 20, 2025 at 3:02 PM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> > For making this work, I think the attached should be about the guts of
> > the code changes. I didn't look at the comments. Right now I can't
> > think of any reason why this can't be done, but some experimentation
> > might reveal some reason that it can't.
>
> I conducted some experiments, and I'm afraid it's not safe to consider
> Memoize for semi or anti joins, unless the inner side is provably
> unique. As an example, please consider:
Thanks for checking that. I was just looking at the spot you'd need to
adjust to prove the inner_unique for anti joins and found I'd written:
/*
* XXX it may be worth proving this to allow a Memoize to be
* considered for Nested Loop Semi/Anti Joins.
*/
Looks like I must have known that at one point in time...
> Perhaps we could spend some planner cycles proving inner_unique for
> anti joins, so that Memoize nodes can be considered for them?
Worth a try. It should be pretty easy to enable, as far as I can see.
It might just be a case of shuffling the cases around in the switch
statement in add_paths_to_joinrel().
David
From | Date | Subject | |
---|---|---|---|
Next Message | Kirill Reshke | 2025-04-09 09:25:54 | Re: tab complete for COPY populated materialized view TO |
Previous Message | Heikki Linnakangas | 2025-04-09 08:53:20 | Re: pgsql: Make cancel request keys longer |