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