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 1vdNbI-00HSgH-2B for pgsql-hackers@arkaria.postgresql.org; Wed, 07 Jan 2026 07:05:01 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vdNbH-00COmx-28 for pgsql-hackers@arkaria.postgresql.org; Wed, 07 Jan 2026 07:05:00 +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 1vdNbH-00COmd-0v for pgsql-hackers@lists.postgresql.org; Wed, 07 Jan 2026 07:05:00 +0000 Received: from mail-qt1-x82f.google.com ([2607:f8b0:4864:20::82f]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vdNbF-0052J5-1D for pgsql-hackers@lists.postgresql.org; Wed, 07 Jan 2026 07:04:59 +0000 Received: by mail-qt1-x82f.google.com with SMTP id d75a77b69052e-4edb6e678ddso25305041cf.2 for ; Tue, 06 Jan 2026 23:04:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fittl.com; s=google; t=1767769495; x=1768374295; darn=lists.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=ZhKJ8LZSvWPMinoaCwKVz7fIZ2iRev3JEep/V4aNpoI=; b=e8+BpVWrjgiKLGOg4XokfGszxmcZuRlDkaxIbRVki7/AflhItuP7MxFRioz7mvLeM1 Q+pXygxV6T7bDGQJgLRWDVEXg7XMb666+oMvngLHCLTBjRuh9botbPXg8juMikThxNji bteVAOEMvx5qW1CM/3K1ZIAebwVS+vCa+BENw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767769495; x=1768374295; 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=ZhKJ8LZSvWPMinoaCwKVz7fIZ2iRev3JEep/V4aNpoI=; b=uThGNrgYudq7/Fjr8k88Pltg90aZp2AQDGrvWQyx0U3DETsSPDike4dvDHI+1zmTT0 bhzh6BRTC9gNuuGmDX/uCVcGH51lwEp+lTNMwaR42olwAPnM2xi2IsFOThgtRpmYnhQH 199Qcc7ekI+BBzjkDzkCn7hJsP+PS7EK46KxWM4D5f5hKOb6c/oPgVwN1gr63obLbw9c Qum8wRNRg/lH9y4YcxWU6Qj5e3AdQVYRcIUA0exeg54URV4hSam6c6OGlB4GGTh1HIwt VoiPmyqppBfHX2qMxRwZEnE7YpCKBZFLg9N/R/1JBqsVTp2Vi0zs8V97z1GGBFpxF+/p 1hHQ== X-Forwarded-Encrypted: i=1; AJvYcCUTEOth1TZY1nKPBwX0m/+wo0VRyph90XWhy3cnalrypVi/A/Pk0zRceazUp/6uuKQkwmXb1OoT921CqdED@lists.postgresql.org X-Gm-Message-State: AOJu0Yzwd4Qqv2DoJuzqPxPJkmFMtm43FjbbWYGgFPJOjUp4qpHvLgzs E5CX2W+idYT2LPIlIKtyqY1SF0HOMb9hrSWNftU6gZyzb18v6YxISplwFoaFcmlWiCxvVf352Uq NM/jaL5Imokp4Imv1BK9PGQowaFx6mb4PMc3SzLZSGpXRtzHy0hz3aXhP X-Gm-Gg: AY/fxX4mTMlpRON+hk96Na4OS+9xQ4ZfY10faY9H6IYk5CokF7IGD7vpFPVB4B4+uHS m4GvNFvbINTdqIhYD9FLuOg7niswdTz6m48Pyg4EX9Bak3nYWWD7KD54naMYsd638kxln7l5WGo HfJAz9Gikn9FQ1XzoN74WjqPc8gWarR3NmWcENpjFj6X96Bh5SNNRzmI1YgEJKheQXHf6+07Em6 5YO0je84o5NMsz08XZggpRtMgx53Mnp+AWAr524D3UYcbrlZOs9Uj+6lxPfrAPF+aqLaXgPoInv DrpPBVk+xVkRmt6WRuxy3tYHY73V X-Google-Smtp-Source: AGHT+IFtPXIn+83PA7sc/RTY6DE9JMF3c99rXlWk6uFQkMP7LKnKRrT8DdbD2Z92FZYN36UYoJclhDwd2TiCqmuOo0c= X-Received: by 2002:ac8:7d0a:0:b0:4ee:146d:771e with SMTP id d75a77b69052e-4ffb4855183mr23808721cf.29.1767769495157; Tue, 06 Jan 2026 23:04:55 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Lukas Fittl Date: Tue, 6 Jan 2026 23:04:19 -0800 X-Gm-Features: AQt7F2raHU4_zZ_Fdgn2vQPK3AUlUGHq-IkPvnXZosHPPi1ACX1eICumMNMS09c Message-ID: Subject: Re: pg_plan_advice To: Robert Haas Cc: Jacob Champion , Dian Fay , Matheus Alcantara , Jakub Wartak , PostgreSQL Hackers , Michael Paquier Content-Type: multipart/alternative; boundary="000000000000cdce4a0647c6e82a" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000cdce4a0647c6e82a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Dec 29, 2025 at 5:15=E2=80=AFPM Lukas Fittl wrote= : > On Mon, Dec 15, 2025 at 12:06=E2=80=AFPM Robert Haas > wrote: > > Here's v7. > > I'm excited about this patch series, and in an effort to help land the > infrastructure, here is a review of 0001 - 0003 to start: > For the review of 0004, I decided to spend a few days to test if the plan generation strategy logic will work for pg_hint_plan, as an existing extension in the ecosystem that is widely used, but functions today by virtue of modifying planner GUCs whilst the planner is running. First of all, as is expected, the extension completely stops working with 0004 in place - because we now only read the GUCs at planner start, the mechanism of modifying them in the middle doesn't work. I don't think we can avoid this. That said, good news: After a bunch of iterations, I get a clean pass on the pg_hint_plan regression tests, whilst completely dropping its copying of core code and hackish re-run of set_plain_rel_pathlist. See [0] for a draft PR (on my own fork of pg_hint_plan) with individual patches that explain some regression test differences. Adding Michael in CC, since he's been thankfully maintaining pg_hint_plan over the years, and I think if 0004 gets merged that should significantly reduce the maintenance burden, independently of what happens with pg_plan_advice - so his input would be useful here. The biggest change in the regression test output was due to how the "Parallel" hint worked in pg_hint_plan (basically it was setting parallel_*_cost to zero, and then messed with the gucs that factor into compute_parallel_worker) -- I think the only sensible thing to do is to change that in pg_hint_plan, and instead rely on rejecting non-partial paths with PGS_CONSIDER_NONPARTIAL if "hard" enforcement of parallelism is requested. That caused some minor plan changes, but I think they can still be argued to be matching the user's intent of "make a scan involving this relation parallel". There were two bugs in 0004 that I had to fix to make this work: In cost_index, we are checking "path->path.parallel_workers =3D=3D 0", but parallel_workers only gets set later in the function, causing the PGS_CONSIDER_NONPARTIAL mask to not be applied. Replacing this with checking the "partial_path" argument instead makes it work. In cost_samplescan, we set the PGS_CONSIDER_NONPARTIAL mask if its a non-partial path, but that causes Sample Scans to always be disabled when setting PGS_CONSIDER_NONPARTIAL on the relation. I think we could simply drop that check, since we never generate partial sample scan paths. Otherwise 0004 looks good to me, and the mechanism of working with mask values felt natural to me, especially in contrast with existing ways to achieve something similar. I did not test partition wise joins, since pg_hint_plan doesn't cover them today. [0]: https://github.com/lfittl/pg_hint_plan/pull/1 Thanks, Lukas --=20 Lukas Fittl --000000000000cdce4a0647c6e82a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Dec 29, 2025 at 5:15=E2=80=AFPM L= ukas Fittl <lukas@fittl.com> w= rote:
On Mon= , Dec 15, 2025 at 12:06=E2=80=AFPM Robert Haas <robertmhaas@gmail.com> wrote:
= > Here's v7.

I'm excited ab= out this patch series, and in an effort to help land the infrastructure, he= re is a review of 0001 - 0003 to start:

For the review of 0004, I decided to spend a few days to test if t= he plan generation strategy logic will
work for pg_hint_plan, as = an existing extension in the ecosystem that is widely used, but functions t= oday
by virtue of modifying planner GUCs whilst the planner is ru= nning.

First of all, as is expected, the extension= completely stops working with 0004 in place - because we now
onl= y read the GUCs at planner start, the mechanism of modifying them in the mi= ddle doesn't work. I don't
think we can avoid this.
=

That said, good news: After a bunch of iterations, I ge= t a clean pass on the pg_hint_plan regression tests,
whilst compl= etely dropping its copying of core code and hackish re-run of set_plain_rel= _pathlist. See [0]
for a draft PR (on my own fork of pg_hint_plan= ) with individual patches that explain some regression test
diffe= rences.

Adding Michael in CC, since he's = been thankfully maintaining pg_hint_plan over the years, and I think if
0004 gets merged that should significantly reduce the maintenance bu= rden, independently of what happens
with pg_plan_advice - so his = input would be useful here.

The biggest change in the r= egression test output was due to how the "Parallel" hint worked i= n pg_hint_plan
(basically it was setting parallel_*_cost to zero,= and then messed with the gucs that factor into
compute_parallel_= worker) -- I think the only sensible thing to do is to change that in pg_hi= nt_plan, and
instead rely on rejecting non-partial paths with PGS= _CONSIDER_NONPARTIAL if "hard" enforcement of
paralleli= sm is requested. That caused some minor plan changes, but I think they can = still be argued to be
matching the user's intent of "mak= e a scan involving this relation parallel".

T= here were two bugs in 0004 that I had to fix to make this work:
<= br>
In cost_index, we are checking "path->path.parallel_w= orkers =3D=3D 0", but parallel_workers only gets
set later i= n the function, causing the PGS_CONSIDER_NONPARTIAL mask to not be applied.= Replacing
this with checking the "partial_path" argume= nt instead makes it work.

In=C2=A0cost_samplescan,= we set the=C2=A0PGS_CONSIDER_NONPARTIAL mask if its a non-partial path, bu= t that
causes Sample Scans to always be disabled when setting=C2= =A0PGS_CONSIDER_NONPARTIAL on the
relation. I think we could simp= ly drop that check, since we never generate partial sample scan paths.
Otherwise 0004 = looks good to me, and the mechanism of working with mask values felt natura= l to me,
especially i= n contrast with existing ways to achieve something similar. I did not test = partition wise joins,
since pg_hint_plan doesn't cover them today.


Thanks,
Lukas

--
<= div>
Lukas Fittl
--000000000000cdce4a0647c6e82a--