| 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: | Whole Thread | Raw Message | 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 |