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
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? |