Re: Partial join

From: Arne Roland <A(dot)Roland(at)index(dot)de>
To: Richard Guo <riguo(at)pivotal(dot)io>
Cc: "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Partial join
Date: 2019-08-19 15:17:21
Message-ID: 22c352db506e4636b397d41a5dcba7e6@index.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

Richard Guo <riguo(at)pivotal(dot)io> wrote:
> Please refer to the code snippet below:
>
> @@ -1164,8 +1164,8 @@ generate_join_implied_equalities(PlannerInfo *root,
> List *sublist = NIL;
>
> /* ECs containing consts do not need any further enforcement */
> if (ec->ec_has_const)
> continue;

Sorry, I'm quite busy currently. And thanks! That was a good read.

I might be wrong, but I think have_partkey_equi_join in joinrels.c should be aware of the const case. My naive approach would be keeping pointers to the first few constant clauses, which are referencing to a yet unmatched partition key, to keep the memory footprint feasible in manner similar to pk_has_clause. The question would be what to do, if there are a lot of const expressions on the part keys. One could palloc additional memory in that case, hoping that it will be quite rare. Or is there a different, better way to go about that?
Thank you for your feedback!

Regards
Arne

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2019-08-19 15:51:43 Re: Duplicated LSN in ReorderBuffer
Previous Message Tom Lane 2019-08-19 15:02:42 Re: Cleanup isolation specs from unused steps

Browse pgsql-performance by date

  From Date Subject
Next Message Barbu Paul - Gheorghe 2019-08-20 13:54:18 Erratically behaving query needs optimization
Previous Message Mariel Cherkassky 2019-08-19 12:32:10 pg11 list partitions vs hash partitions