Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hzjQS-0006SJ-J7 for pgsql-hackers@arkaria.postgresql.org; Mon, 19 Aug 2019 15:18:28 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hzjPT-0007Ux-H1 for pgsql-hackers@arkaria.postgresql.org; Mon, 19 Aug 2019 15:17:27 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hzjPT-0007RX-5K for pgsql-hackers@lists.postgresql.org; Mon, 19 Aug 2019 15:17:27 +0000 Received: from mail.index.de ([213.160.90.22]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hzjPP-0008FS-Oo for pgsql-hackers@lists.postgresql.org; Mon, 19 Aug 2019 15:17:26 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.index.de (Postfix) with ESMTP id B747A446B30; Mon, 19 Aug 2019 15:17:22 +0000 (UTC) Received: from mail.index.de ([127.0.0.1]) by localhost (mail.index.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id gIBJ4YG_LYst; Mon, 19 Aug 2019 15:17:22 +0000 (UTC) Received: from remote.index.de (unknown [217.199.72.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.index.de (Postfix) with ESMTPSA id 8D06244579F; Mon, 19 Aug 2019 15:17:22 +0000 (UTC) Received: from invidia.index-gruppe.local (192.168.3.140) by acedia.index-gruppe.local (192.168.3.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1034.26; Mon, 19 Aug 2019 17:17:22 +0200 Received: from acedia.index-gruppe.local (192.168.3.121) by invidia.index-gruppe.local (192.168.3.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1034.26; Mon, 19 Aug 2019 17:17:21 +0200 Received: from acedia.index-gruppe.local ([fe80::ecd1:5d0a:a834:dd56]) by acedia.index-gruppe.local ([fe80::ecd1:5d0a:a834:dd56%5]) with mapi id 15.01.1034.033; Mon, 19 Aug 2019 17:17:21 +0200 From: Arne Roland To: Richard Guo CC: "pgsql-hackers@lists.postgresql.org" Subject: Re: Partial join Thread-Topic: Partial join Thread-Index: AQHVRhDNZ8hUeRNKjUmj3sfzUQx80qbl85QWgAATZwCAACNfrYABWhaAgAUlS6I= Date: Mon, 19 Aug 2019 15:17:21 +0000 Message-ID: <22c352db506e4636b397d41a5dcba7e6@index.de> References: <9dc03e949e9b4327a0d074da9ab44318@index.de> , In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.3.146] Content-Type: multipart/alternative; boundary="_000_22c352db506e4636b397d41a5dcba7e6indexde_" MIME-Version: 1.0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --_000_22c352db506e4636b397d41a5dcba7e6indexde_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Richard Guo wrote: > Please refer to the code snippet below: > > @@ -1164,8 +1164,8 @@ generate_join_implied_equalities(PlannerInfo *root, > List *sublist =3D NIL; > > /* ECs containing consts do not need any further enforcem= ent */ > 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 b= e aware of the const case. My naive approach would be keeping pointers to t= he first few constant clauses, which are referencing to a yet unmatched par= tition key, to keep the memory footprint feasible in manner similar to pk_h= as_clause. The question would be what to do, if there are a lot of const ex= pressions 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 --_000_22c352db506e4636b397d41a5dcba7e6indexde_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Richard Guo <riguo@pivotal.io= > wrote:
> Please refer to the code snippet below:
>
> @@ -1164,8 +1164,8 @@ generate_join_implied_equalitie= s(PlannerInfo *root,
>                 List   &n= bsp;   *sublist =3D NIL;
>
>                 /= * ECs containing consts do not need any further enforcement */
>                 i= f (ec->ec_has_const)
>                 &= nbsp;       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 approac= h would be keeping pointers to the first few constant clauses, which a= re referencing to a yet unmatched partition key, to keep the memory footpri= nt 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 t= hat it will be quite rare. Or is there a different, better way to go about = that?
Thank you for your feedback!

Regards
Arne
--_000_22c352db506e4636b397d41a5dcba7e6indexde_--