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 1na8aa-0003IV-5A for pgsql-hackers@arkaria.postgresql.org; Fri, 01 Apr 2022 04:08:44 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1na8aY-00047N-Q9 for pgsql-hackers@arkaria.postgresql.org; Fri, 01 Apr 2022 04:08:42 +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 1na8aY-00047B-HY for pgsql-hackers@lists.postgresql.org; Fri, 01 Apr 2022 04:08:42 +0000 Received: from mail-lf1-x12f.google.com ([2a00:1450:4864:20::12f]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1na8aW-0004a8-Ml for pgsql-hackers@postgresql.org; Fri, 01 Apr 2022 04:08:42 +0000 Received: by mail-lf1-x12f.google.com with SMTP id p10so2598649lfa.12 for ; Thu, 31 Mar 2022 21:08:40 -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=QO7SMzn7FCmJ/RXf1rwL8V16vSn+ee3g5yC7JRy3oYA=; b=dZSwFAFad4XhKNJMsgiWbSBbn2w60vaXMUZk/4x0iEbV34TD5MKDuMWYweSxwDR8TG 9fGw2G3eLR3WoCRDvEPJnU8krQdQ1UsVmaCiPVbEnmDhW5B0xlly0ddsEsBaqpt+ZHp9 g7lkwBMkf8UReVXPAiNVn5q6u9VkaG4tU0KAasLNOsThPfCijm+6BvO3y7FYrWtr/DF2 joUnALfxMcVRv1tqL9cU4nc7snfLGeVt2tXxnprJ0nxeLKaIFPS8b8vDSMNYw3g5eq/B 4ggIlPBL7fP8Q3nz/hJl9GIiSgLIDic+SWp+FsxI6ylS77vkNq2k//TzJk6zVMal1X8E Cx2Q== 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=QO7SMzn7FCmJ/RXf1rwL8V16vSn+ee3g5yC7JRy3oYA=; b=Yg7RRDhKbxxuDyNO7n3bcq60bL6hgkXeD72pXWydP/vZpt6M/lUDJ3tCyySzU86Jcp 3TT/FrPhjVI0speDqjQlcAU6OhvztSFxkZKYiWNVv9+d1v36MaB0NbCCEbaKOcrqOaOE JszZDaJCc1DGch6HAFY/OzzdBZghiGrLxOnauRL7eK8vrkaCHGmypLTxR5Pm6eECitwP PQtALVzhbhit4cvYZuTQyR8ElfS4YWu20OevqCdG7tP9UbqzW3uxgECC/S9FLuBnWCmH +gVWKZd8D6kK69PnK73ShjhlY/5jucAH4bbuST/ZuCCKEgSnW21sdJFLA3Nq7Elcm573 7MAA== X-Gm-Message-State: AOAM533bV0WKEPMVwVZN9eT8cgTm8s29QRBizUgeD9q1KQsPGIDJe07o GDG9GRcS4sxygyEA/VBe1AtM5TnLbu6+4WWJsQ0= X-Google-Smtp-Source: ABdhPJzJnbAcYq8gT3nDuhUpUM5fCEPuGW3b4oQtHE8VKCsF1wKUM5Iq/zfsRHbzFFMdDHj53JWdgyE5ehJzt6+4OO8= X-Received: by 2002:a05:6512:3a95:b0:44a:6189:dad1 with SMTP id q21-20020a0565123a9500b0044a6189dad1mr12746149lfu.334.1648786119718; Thu, 31 Mar 2022 21:08:39 -0700 (PDT) MIME-Version: 1.0 References: <215356.1647286703@sss.pgh.pa.us> In-Reply-To: From: David Rowley Date: Fri, 1 Apr 2022 17:08:27 +1300 Message-ID: Subject: Re: generic plans and "initial" pruning To: Amit Langote Cc: Robert Haas , 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 Fri, 1 Apr 2022 at 16:09, Amit Langote wrote: > definition of PlannedStmt says this: > > /* ---------------- > * PlannedStmt node > * > * The output of the planner > > With the ideas that you've outlined below, perhaps we can frame most > of the things that the patch wants to do as the planner and the > plancache changes. If we twist the above definition a bit to say what > the plancache does in this regard is part of planning, maybe it makes > sense to add the initial pruning related fields (nodes, outputs) into > PlannedStmt. How about the PartitionPruneInfos go into PlannedStmt as a List indexed in the way I mentioned and the cache of the results of pruning in EState? I think that leaves you adding List *partpruneinfos, Bitmapset *minimumlockrtis to PlannedStmt and the thing you have to cache the pruning results into EState. I'm not very clear on where you should stash the results of run-time pruning in the meantime before you can put them in EState. You might need to invent some intermediate struct that gets passed around that you can scribble down some details you're going to need during execution. > One question is whether the planner should always pay the overhead of > initializing this bitmapset? I mean it's only worthwhile if > AcquireExecutorLocks() is going to be involved, that is, the plan will > be cached and reused. Maybe the Bitmapset for the minimal locks needs to be built with bms_add_range(NULL, 0, list_length(rtable)); then do bms_del_members() on the relevant RTIs you find in the listed PartitionPruneInfos. That way it's very simple and cheap to do when there are no PartitionPruneInfos. > > 4. It's a bit disappointing to see RelOptInfo.partitioned_rels getting > > revived here. Why don't you just add a partitioned_relids to > > PartitionPruneInfo and just have make_partitionedrel_pruneinfo build > > you a Relids of them. PartitionedRelPruneInfo already has an rtindex > > field, so you just need to bms_add_member whatever that rtindex is. > > Hmm, not all Append/MergeAppend nodes in the plan tree may have > make_partition_pruneinfo() called on them though. For Append/MergeAppends without run-time pruning you'll want to add the RTIs to the minimal locking set of RTIs to go into PlannedStmt. The only things you want to leave out of that are RTIs for the RTEs that you might run-time prune away during AcquireExecutorLocks(). David