Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vN92N-00CEPJ-1F for pgsql-hackers@arkaria.postgresql.org; Sun, 23 Nov 2025 12:17:51 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vN92M-00ETJH-0I for pgsql-hackers@arkaria.postgresql.org; Sun, 23 Nov 2025 12:17:50 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vN92L-00ETJ9-2S for pgsql-hackers@lists.postgresql.org; Sun, 23 Nov 2025 12:17:50 +0000 Received: from mail-ed1-x52a.google.com ([2a00:1450:4864:20::52a]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vN92K-0013ZO-00 for pgsql-hackers@postgresql.org; Sun, 23 Nov 2025 12:17:49 +0000 Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-640860f97b5so4822385a12.2 for ; Sun, 23 Nov 2025 04:17:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763900266; x=1764505066; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=w7Ls5bsfKM8YwIZU+rlVwQ8RoIdvIl1wBh5ZyAcl0Lc=; b=EutYb6rqZSoAeb938laEZjlRBeynHK7PwVZISKjzFvQULh8gu8LsLOD/Hbg67V/bCr VbBomopQ6uAjaWKpuoXThqbcO1tvcZngsSYNmTA9tzfgmeu0x377d7azepO7+vB94xcZ Qm2pdoiBvhv9Q/wFQJ1ED+dcgk1+QSRsLDcrmB3Lu3IxAoR3KfCOqm2CzUOxTn1gQzwi 9f8BJFkfaAjzDlRnCnh/Av5kd2fu7oUOzOBuv9MtSyapBWZReW4C2MVk8TnhVzooQNeB qr+p7VXx10d1YkaqCLA0uROgxSZbVKGRPJ6+FVV6WuQj4MFalXvFz4xVUW4tkKeXpkyJ 1Hyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763900266; x=1764505066; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=w7Ls5bsfKM8YwIZU+rlVwQ8RoIdvIl1wBh5ZyAcl0Lc=; b=A3AHp+7TpfpXQtBinEokKd9TD3IP/yfrtJ/7aouasM7tXJ+weI4xnSwdKYhuI9wkxG 0Ydv0taFwBfX5F40o/3MnH/s45Ja5f2kZ2Ev2mEbXhAteX/QacEyqw6rHCzWnzTxF1Km wW3N1eLGUnDAJUAs7h44zOcLS58F1OwsXGAvTKpJY+MaEN8vjue2iXcyaB9D7UVLg37i QqtfDGDmxqZ/mwOi8ybt8Pa8Df9IOigjMGSTh+l+QSIuSoDw78HkG3Nm9sSKknKHlCqr o/JycGd27GEwRmqzn1m555VrRXAKUgYG4ZJeRCtJvR/jv0xAAGyW2loZFjfyGaZ6OC4w izrQ== X-Forwarded-Encrypted: i=1; AJvYcCV9TSauBEjwDDXol/arPWHRiBJxG91U6tRqTancD0s2Wg2wwjJP461aQnKX00UnjWy43NRNgpiVQdNr3c75@postgresql.org X-Gm-Message-State: AOJu0YyA7WRf5+nWyFXsG52vH2Hs3ye6dWX7QJ6rEJ8sqc6rXDTVK0cW BREvX4m+VjiC5PqVHwhexnnXjHScvL5S/dKFgFVwRvh4J1D9oujdUyWlcU5mljiS2/MSr2w4QJP qwjD6wpFZwNtfWqJ5kAWskW1CXLU8NYk= X-Gm-Gg: ASbGncsVpb4lR0m9bp2pIyo1KXPCQyPk/jXlnkqcVtrNX1e0Wb7SzPCIDFHw8LIpdi9 doNKQzfy64UKY0fGPCXgW/SqiQZe9+esou4jhVmCbV5HcDsuEVMgt6tmNKHzlUgtnVt7zIzfCMH cyNuy91P6fso/vkcY+nSC2PXDL/drOFPaL77HbNu6uVRXdTbfmtEwyjDR2ElwwmVJ4oiM57ZYxH VZ6h52Klhj+yl+EdZIUe0e3/hTgaxjUehUlpanqPz0kuWaeDfFDSXsN/JUJ5UlJqCmbsU3n4D6U kDSUhjF+eSE= X-Google-Smtp-Source: AGHT+IGwYnypEmp2+1BNmu2tof6SlRpkmW4ayl78uD/im02S66OGA+QgLwe75OkYDgvnCLE1hUqzls2THOBckx0I2cs= X-Received: by 2002:a17:907:3e82:b0:b73:875f:2858 with SMTP id a640c23a62f3a-b767156746bmr940073666b.15.1763900266021; Sun, 23 Nov 2025 04:17:46 -0800 (PST) MIME-Version: 1.0 References: <54c35fb9-da3a-4754-ab8c-46ed0b612465@vondra.me> <684c70d7-180e-461d-9377-600c2db581ba@vondra.me> <605328.1747710381@sss.pgh.pa.us> <691261.1747755511@sss.pgh.pa.us> In-Reply-To: From: Tender Wang Date: Sun, 23 Nov 2025 20:17:11 +0800 X-Gm-Features: AWmQ_bm8fRxp7Fepa_rzYkCDq-edYnov4L8DVUW1TTdqkNh1rlAXxsP_weVElYs Message-ID: Subject: Re: generic plans and "initial" pruning To: Amit Langote Cc: Tom Lane , Alexander Lakhin , Tomas Vondra , Robert Haas , Alvaro Herrera , Andres Freund , Daniel Gustafsson , David Rowley , PostgreSQL Hackers , Thom Brown Content-Type: multipart/alternative; boundary="000000000000c687d50644420800" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000c687d50644420800 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Amit Langote =E4=BA=8E2025=E5=B9=B411=E6=9C=8820= =E6=97=A5=E5=91=A8=E5=9B=9B 15:30=E5=86=99=E9=81=93=EF=BC=9A > On Mon, Nov 17, 2025 at 9:50=E2=80=AFPM Amit Langote > wrote: > > On Wed, Nov 12, 2025 at 11:17=E2=80=AFPM Amit Langote > wrote: > > > * Enable pruning-aware locking in cached / generic plan reuse (0004): > > > extends GetCachedPlan() and CheckCachedPlan() to call ExecutorPrep() > > > on each PlannedStmt in the CachedPlan, locking only surviving > > > partitions. Adds CachedPlanPrepData to pass this through plan cache > > > APIs and down to execution via QueryDesc. Also reinstates the > > > firstResultRel locking rule added in 28317de72 but later lost due to > > > revert of the earlier pruning patch, to ensure correctness when all > > > target partitions are pruned. > > > > Looking at the changes to executor/function.c, I also noticed that I > > had mistakenly allocated the ExecutorPrep state in > > SQLFunctionCache.fcontext whereas the correct context for execution > > related state is SQLFunctionCache.subcontext. In the updated patch, > > I've made postquel_start() reparent the prep EState's es_query_cxt to > > subcontext from fcontext. I also did not have a test case that > > exercised cached plan reuse for SQL functions, so I added one. I split > > the function.c's GetCachedPlan() + CachedPlanPrepData plumbing into a > > new patch 0005 so it can be reviewed separately, since it is the only > > non-mechanical call-site change. > > I also noticed a bug in the prep cleanup logic that runs when a cached > plan becomes invalid during the prep phase. Patch 0005 fixes that and > adds a regression test that exercises the invalidation path. This will > be folded into 0004 later. > I spent time looking at these patches. I search all places that call GetCachedPlan(), and we always pass &cprep(CachedPlanPrepData) to GetCachedPlan(). In PrepAndCheckCachedPlan(), if the plan_cache_mode is force_generic_plan, the LockPolicy is always LOCK_UNPRUNED. Because *cprep has never been NULL. It seems that the LockPolicy has no chance to be LOCK_ALL. Do I miss something here? --=20 Thanks, Tender Wang --000000000000c687d50644420800 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Amit Langote &l= t;amitlangote09@gmail.com>= ; =E4=BA=8E2025=E5=B9=B411=E6=9C=8820=E6=97=A5=E5=91=A8=E5=9B=9B 15:30=E5= =86=99=E9=81=93=EF=BC=9A
On Mon, Nov 17, 2025 at 9:50=E2=80=AFPM Amit Langote <amitlangote09@gmail.c= om> wrote:
> On Wed, Nov 12, 2025 at 11:17=E2=80=AFPM Amit Langote <amitlangote09@gmail.com> wrote:
> > * Enable pruning-aware locking in cached / generic plan reuse (00= 04):
> > extends GetCachedPlan() and CheckCachedPlan() to call ExecutorPre= p()
> > on each PlannedStmt in the CachedPlan, locking only surviving
> > partitions. Adds CachedPlanPrepData to pass this through plan cac= he
> > APIs and down to execution via QueryDesc. Also reinstates the
> > firstResultRel locking rule added in 28317de72 but later lost due= to
> > revert of the earlier pruning patch, to ensure correctness when a= ll
> > target partitions are pruned.
>
> Looking at the changes to executor/function.c, I also noticed that I > had mistakenly allocated the ExecutorPrep state in
> SQLFunctionCache.fcontext whereas the correct context for execution > related state is SQLFunctionCache.subcontext.=C2=A0 In the updated pat= ch,
> I've made postquel_start() reparent the prep EState's es_query= _cxt to
> subcontext from fcontext. I also did not have a test case that
> exercised cached plan reuse for SQL functions, so I added one. I split=
> the function.c's GetCachedPlan() + CachedPlanPrepData plumbing int= o a
> new patch 0005 so it can be reviewed separately, since it is the only<= br> > non-mechanical call-site change.

I also noticed a bug in the prep cleanup logic that runs when a cached
plan becomes invalid during the prep phase. Patch 0005 fixes that and
adds a regression test that exercises the invalidation path. This will
be folded into 0004 later.

<= span class=3D"gmail_signature_prefix">--
Thanks,
Tender Wang
--000000000000c687d50644420800--