Re: A problem about partitionwise join

From: Richard Guo <guofenglinux(at)gmail(dot)com>
To: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: A problem about partitionwise join
Date: 2024-08-12 03:54:32
Message-ID: CAMbWs49akrNX-iLmCnpifd52YxeP07dHiBnS-uyt=OnUzH1kpQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Mar 25, 2024 at 7:09 PM Ashutosh Bapat
<ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> wrote:
> I think we need some way to avoid two different ways of looking up partition keys - if we can't teach the EC machinery to produce clauses with partition keys (always), we need to teach EC to contain partition keys in case of outer joins. Tom alluded to this but I haven't seen any proposal. The potential danger with the current patch is that it will continue to have two loops even if we fix one of the above cases in future.

Sorry for not replying to this comment before pushing the patch. I
understand your concern and agree that it would be ideal if the
partitionwise join matching logic relied solely on ECs. However,
implementing that would require a lot of changes to the EC mechanism,
and I'm not sure if that will happen in the near future. And if we do
achieve this in the future, I believe many parts of the code, not just
the loops here, will need to be modified to leverage the new EC
mechanism.

Thanks
Richard

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2024-08-12 04:00:34 Re: Conflict detection and logging in logical replication
Previous Message David Rowley 2024-08-12 03:43:55 Re: Do we still need parent column in pg_backend_memory_context?