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 1hsaaj-0006A0-VS for pgsql-hackers@arkaria.postgresql.org; Tue, 30 Jul 2019 22:27:34 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hsaai-00041j-4f for pgsql-hackers@arkaria.postgresql.org; Tue, 30 Jul 2019 22:27:32 +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 1hsaah-0003xe-Qh for pgsql-hackers@lists.postgresql.org; Tue, 30 Jul 2019 22:27:31 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hsaab-0001P2-EF for pgsql-hackers@lists.postgresql.org; Tue, 30 Jul 2019 22:27:31 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id x6UMRJFm006780; Tue, 30 Jul 2019 18:27:19 -0400 From: Tom Lane To: David Rowley cc: Amit Langote , Yuzuko Hosoya , PostgreSQL Hackers Subject: Re: Runtime pruning problem In-reply-to: References: <001001d4f44b$2a2cca50$7e865ef0$@lab.ntt.co.jp> <2018.1555473241@sss.pgh.pa.us> <2923.1555474214@sss.pgh.pa.us> <17368.1555608352@sss.pgh.pa.us> Comments: In-reply-to David Rowley message dated "Tue, 23 Jul 2019 20:49:52 +1200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <6778.1564525639.1@sss.pgh.pa.us> Date: Tue, 30 Jul 2019 18:27:19 -0400 Message-ID: <6779.1564525639@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk David Rowley writes: > The part I wouldn't mind another set of eyes on is the ruleutils.c > changes. Um, sorry for not getting to this sooner. What I had in mind was to revert 1cc29fe7c's ruleutils changes entirely, so that ruleutils deals only in Plans not PlanStates. Perhaps we've grown some code since then that really needs the PlanStates, but what is that, and could we do it some other way? I'm not thrilled with passing both of these around, especially if the PlanState sometimes isn't there, meaning that no code in ruleutils could safely assume it's there anyway. regards, tom lane