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 1oGjsa-0005P5-Fx for pgsql-hackers@arkaria.postgresql.org; Wed, 27 Jul 2022 16:27:24 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oGjsZ-0007lT-5d for pgsql-hackers@arkaria.postgresql.org; Wed, 27 Jul 2022 16:27:23 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oGjsY-0007lJ-QT for pgsql-hackers@lists.postgresql.org; Wed, 27 Jul 2022 16:27:22 +0000 Received: from mail-qk1-x72e.google.com ([2607:f8b0:4864:20::72e]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oGjsW-0002BV-Bq for pgsql-hackers@postgresql.org; Wed, 27 Jul 2022 16:27:21 +0000 Received: by mail-qk1-x72e.google.com with SMTP id m16so13636454qka.12 for ; Wed, 27 Jul 2022 09:27:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7/UDAAqIuUK3xuIohuA9yOdM4TC1Y6b9kDBP0H+72xs=; b=UQi3E//MTJtTNNYAFkSbJDdDNJiLZtdc4ECfSNIUU6PFSn9YPgKwGEh+YSuoDZ/sY0 +YERTBb/plDu1j+ZZdqWJCWU7vWU/e2Z9yyma0R/6TH8cfPw5u8BFqaFRTRAiU7uw2Ef JENUx4rY92mB+sFLJZ2JzPtA+TzyvEM+OK9c+hsUxE4drDm3xtAaDtyXRTKqvEhWQHNK dRGtdk/P8J/67X5f6v9UkKIhZuSJdDVYN2W3eaXSVOUWXoWBacabKE78c5sEdCruKR44 zv/+X2B04eog8Kx+wfs1VxC/O2XxQLtuUBWYEcuScN/tBmKjIhTFIskMnn+2JaYH3G7c hi2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7/UDAAqIuUK3xuIohuA9yOdM4TC1Y6b9kDBP0H+72xs=; b=TNdLO9dwWnTU70+kwbdM4pdPRIYhw4bLVGI8WINqASrb8kass5fM0S0atUCjduUrWf hwlpB1Ney3BDf+HE1aUqhexIAczyeNyixpGtIIigBHpOPzHpP2XP2e7kYeffz8igGPDz r6ZaBO8XGZCSwUHIX7khEvBf9ylWzuYYMqunJOZMExcJ1hZ/hkbVjWQ6z15DPNDBJFly xDz1Ng/LeVhqYg92XFvIvFGBogA8M48p5pahsO+ansZG+6i6aONJqftaQLbdpXh/AefQ bDZMz7FCw1imMbQKf4gueJDABwlJ6++dmp2evQESg81ODNS712niBO3m3Y3dXSqVMUr7 BDuA== X-Gm-Message-State: AJIora/GhsjoZAQdH3aSBrxy0RdTpAOy3GzJ1tjDY6UK6gxj/y9L1VIy 6QdB3ey+Q3WlwxVgZSW0zqF7IAWFvwBYS8SIWUA= X-Google-Smtp-Source: AGRyM1vkw0gnEv9aX6K8A50yIUbHNLqL7oCfH4CErkeOuk0L1w32kZltwL2CmLsh+ymvq/RTlSnon1Fj776SsmtCoVM= X-Received: by 2002:a05:620a:472a:b0:6b6:15b3:5cbf with SMTP id bs42-20020a05620a472a00b006b615b35cbfmr16817545qkb.127.1658939238816; Wed, 27 Jul 2022 09:27:18 -0700 (PDT) MIME-Version: 1.0 References: <215356.1647286703@sss.pgh.pa.us> In-Reply-To: From: Robert Haas Date: Wed, 27 Jul 2022 12:27:06 -0400 Message-ID: Subject: Re: generic plans and "initial" pruning To: Amit Langote Cc: Jacob Champion , Zhihong Yu , David Rowley , Tom Lane , PostgreSQL-development Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Jul 26, 2022 at 11:01 PM Amit Langote wrote: > Needed to be rebased again, over 2d04277121f this time. 0001 adds es_part_prune_result but does not use it, so maybe the introduction of that field should be deferred until it's needed for something. I wonder whether it's really necessary to added the PartitionPruneInfo objects to a list in PlannerInfo first and then roll them up into PlannerGlobal later. I know we do that for range table entries, but I've never quite understood why we do it that way instead of creating a flat range table in PlannerGlobal from the start. And so by extension I wonder whether this table couldn't be flat from the start also. -- Robert Haas EDB: http://www.enterprisedb.com