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 1hv7mR-00039k-VE for pgsql-hackers@arkaria.postgresql.org; Tue, 06 Aug 2019 22:18:08 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hv7mQ-0004JS-R7 for pgsql-hackers@arkaria.postgresql.org; Tue, 06 Aug 2019 22:18:06 +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 1hv7mQ-0004JL-Iu for pgsql-hackers@lists.postgresql.org; Tue, 06 Aug 2019 22:18:06 +0000 Received: from mail-qt1-x842.google.com ([2607:f8b0:4864:20::842]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hv7mN-000137-Pe for pgsql-hackers@lists.postgresql.org; Tue, 06 Aug 2019 22:18:06 +0000 Received: by mail-qt1-x842.google.com with SMTP id x22so12905174qtp.12 for ; Tue, 06 Aug 2019 15:18:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=9a/49/7ihR8ZaCCoHloJ7ZpoRvoHq70r1jmqNzlgE+Y=; b=C9DYlY10Z3JUGv3WBZNWymt9NgDCKNhrfWmh7BcKiqd84Ysf6vaoagxQ/YWr/zCBmQ zHN/XxKTgY9selx2Q+Li0nL4hJgjtCPPrPI2DbYBrYjtRWURNnoHofWtJ4Rl4b2Db32M ip943OEBZjx3LFGoedYrxUv8dJnSTDh01uQ7ZLB4dREt+gps/+mi1oiJptq5qVDg6yoD RSJHDrmH1ZEzVCeN2yWysLB/agHdq3r8Bz+YuzNA2eRzSHXwOzkp3/urGsXuGHQdrrKB rdWA0LNw+OSDO1KE69CHO1VbUl3OQcey1bM5XIst/HrR1VbVFW1vW7yhndeYiIErG05F UHZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=9a/49/7ihR8ZaCCoHloJ7ZpoRvoHq70r1jmqNzlgE+Y=; b=eTBGuCPu1Z9l0aMgZGBdC7ZI+jlUOja3lQAPu7cepb8H9h/Bwek+7nHe2Zgs4alMhz 372Gmo9ioM2hUhnABvag5+I4CNcQqNHaM8ULpFT01VSwNzc3BB1/+U7jROdcT6dNDAom apIyrLpqmBGUdeFTue4C8Ng0QERPpR5tSQnO1PkryM2+SBA4A4EK2DUVfqiZb79Yc3Tn u74kqGcFTz4zC1RKaUFDrTFOjhVuzTpvxw4klXENFsMly/7LbYIhBAWtsog2vlZktvDe yPd2kmuRs9yaqUuiVvB5DAqBnnRzum+37CBtga4FdbOZhclsaX0gLTgOPWGw8bc0WXJr z4BQ== X-Gm-Message-State: APjAAAVreuHrJdGJhfsJdA5ffC7ElgbnR9hNNtJT/xN2iGoMQT4NhjM7 /XhKaEHfiLxMquBokgSsEACFdw== X-Google-Smtp-Source: APXvYqx343ebvxMoAzaJi/xLS9mCm3VlQ3IpPIwBJRjbB5F6oGH6kFvlmawrPyDJaCcZBECTMp+Lxg== X-Received: by 2002:ac8:28e2:: with SMTP id j31mr5366297qtj.274.1565129882211; Tue, 06 Aug 2019 15:18:02 -0700 (PDT) Received: from nimloth.alvh.no-ip.org ([190.217.183.1]) by smtp.gmail.com with ESMTPSA id u4sm38455659qkb.16.2019.08.06.15.18.01 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Tue, 06 Aug 2019 15:18:01 -0700 (PDT) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id C20B91207B4; Tue, 6 Aug 2019 18:17:59 -0400 (-04) Date: Tue, 6 Aug 2019 18:17:59 -0400 From: Alvaro Herrera To: Amit Langote Cc: yuzuko , shawn wang , Shawn Wang , PostgreSQL Hackers Subject: Re: Problem with default partition pruning Message-ID: <20190806221759.GA9127@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20190806171740.GA7610@alvherre.pgsql> User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2019-Aug-06, Alvaro Herrera wrote: > Well, if this is really all that duplicative, one thing we could do is > run this check in get_partprune_steps_internal only if > constraint_exclusion is a value other than on; we should achieve the > same effect with no repetition. Patch for that is attached. However, > if I run the server with constraint_exclusion=on, the regression test > fail with the attached diff. I didn't look at what test is failing, but > it seems to me that it's not really duplicative in all cases, only some. > Therefore we can't do it. Right ... One of the failing cases is one that was benefitting from constraint_exclusion in the location where we were doing it previously. I think trying to fix this problem by selectively moving where to apply constraint exclusion would be very bug-prone, and hard to detect whether we're missing one spot or doing it multiple times in some other cases. So I think we shouldn't try. If this is a real problem, then we should add a flag to the reloptinfo and set it when we've done pruning, then do nothing if we already did it. I'm not sure that this is correct, and I'm even less sure that it is worth the trouble. In short, I propose to get this done as the patch I posted in https://postgr.es/m/20190806133053.GA23706@alvherre.pgsql Cheers -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services