Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kjvj4-0007xL-28 for pgsql-hackers@arkaria.postgresql.org; Tue, 01 Dec 2020 02:49:10 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kjvj3-0002xi-1O for pgsql-hackers@arkaria.postgresql.org; Tue, 01 Dec 2020 02:49:09 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kjvj2-0002xa-Qu for pgsql-hackers@lists.postgresql.org; Tue, 01 Dec 2020 02:49:08 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kjvj0-0001Kz-GQ for pgsql-hackers@lists.postgresql.org; Tue, 01 Dec 2020 02:49:08 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 0B12mqFm1357738; Mon, 30 Nov 2020 21:48:52 -0500 From: Tom Lane To: Corey Huinker cc: Alvaro Herrera , Kyotaro Horiguchi , keisuke.kuroda.3862@gmail.com, tatsuro.yamada.tf@nttcom.co.jp, pgsql-hackers@lists.postgresql.org, amitlangote09@gmail.com, tatsuhito.kasahara.rd@hco.ntt.co.jp Subject: Re: Huge memory consumption on partitioned table with FKs In-reply-to: References: <20201126.121818.26523414172308697.horikyota.ntt@gmail.com> <20201201000345.GA15098@alvherre.pgsql> Comments: In-reply-to Corey Huinker message dated "Mon, 30 Nov 2020 21:38:05 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1357736.1606790932.1@sss.pgh.pa.us> Date: Mon, 30 Nov 2020 21:48:52 -0500 Message-ID: <1357737.1606790932@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Corey Huinker writes: > Given that we're already looking at these checks, I was wondering if this > might be the time to consider implementing these checks by directly > scanning the constraint index. Yeah, maybe. Certainly ri_triggers is putting a huge amount of effort into working around the SPI/parser/planner layer, to not a lot of gain. However, it's not clear to me that that line of thought will work well for the statement-level-trigger approach. In that case you might be dealing with enough tuples to make a different plan advisable. regards, tom lane