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 1vmzjl-0013z8-1f for pgsql-hackers@arkaria.postgresql.org; Mon, 02 Feb 2026 19:37:29 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vmzjk-000yLn-0v for pgsql-hackers@arkaria.postgresql.org; Mon, 02 Feb 2026 19:37:28 +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 1vmzjj-000yLe-31 for pgsql-hackers@lists.postgresql.org; Mon, 02 Feb 2026 19:37:27 +0000 Received: from mail-pf1-x444.google.com ([2607:f8b0:4864:20::444]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1vmzjh-00000000iP3-1IX5 for pgsql-hackers@lists.postgresql.org; Mon, 02 Feb 2026 19:37:27 +0000 Received: by mail-pf1-x444.google.com with SMTP id d2e1a72fcca58-81e8a9d521dso2842391b3a.2 for ; Mon, 02 Feb 2026 11:37:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1770061043; cv=none; d=google.com; s=arc-20240605; b=h4xGNC6PK2sTK6pVVrupbWirI7y+Z1TeM6YKyO8QhT1+2TRhefdPk7oexlc1ZQPusz aT0lsxRt/JYdeUgqvs0tp76v5tngWeMXUSr2gEyv0+4MHZtNIeiy05h3EKNEHlgPZAum hqTZ4Ebri1YQ6TlVyjHMBzCKVvVbDaGoZy/u6XSoJAUqMX8VKsjSJVMlGJ9vqbm3icvT nluvyAgSdVzUNUPQ0Pwbhi8Kel98KlCCIB9CjwOGkKanQSwcaOoQYGMuMl1LE2OyP3NM 1+o57cllcKMIQbhZZhhgxUVhc9ED9/1G5QbvLnuzRloK4hgBbzGziXVOmb1WLYAiQ3Pk ZAsQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=sjkjtl58McfrRUALTHuiPinldWDj9UtmS+Sr/vIsDr8=; fh=o1VIpbYJAv95G/jIk6nKe3q7GOm/vgABe85MBPrAJko=; b=LpyuJoXFJc+jOmzY3TAcpl6lyFFkjNxsmkA81XsSD8s4XJmO0X7AvSUi9e7H525M6/ gu32Jy9tl4RRZgsOEiDkHFPaMDKsUoj2o8QDHiHvpFk0XQ8VWjSJ5IApe1ubadMwpUyu HRIpeLSd+Da5uOgIDpczyKL8Thqjs+RKIfzwbO89VBlFnuVlaIUw0+7OE0hYRCqT7+0K 8eqybdPzH15iI/+VGFVOd6owdj+PjR1xeAFNnjaIedSIPUsWX15hCyfUPagiimomPh9B GpXclv2Hj1Yt1+wI1cvoC5eP+W01laeXNBuz0S7keCW9xsMFFNQvPGLTlUFcf/3T8c9V xnAQ==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770061043; x=1770665843; 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=sjkjtl58McfrRUALTHuiPinldWDj9UtmS+Sr/vIsDr8=; b=WoPTInRhYFHal3aMjjQzemquXGgW8su+jO45DowBkut2MdNQna+irU0IWxv0lORfgl nKmDuwcxsSJIPb4WxXdildM+6p9HpH8bvamApTgjC7UBAKPHcsOAJogbKwmoWV9D3fNx D+cBqwGWLd/jyXZzRXSs3SOBvgX6ysXmctUNmAdBIcYBjD2gk/jsIo062Gx2FUjDp0/0 WgLJoOV8WEtZCbVcWk1UDsHYR3jJt1DPLzUCLZUc7vNbxSf7ietFOhGyofIlBKWz9MVb yEZYrF9SOdEQzEU8yWVaBQvGNo5D5U60TuVdeFWmM1QbM9W+/RizySLMT+uuvEWM374C +HLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770061043; x=1770665843; 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=sjkjtl58McfrRUALTHuiPinldWDj9UtmS+Sr/vIsDr8=; b=H61EqCWowuwoRyBRRim/sW/BQKw4yTwYV8JaHKsNXapr/+pZZj6fJ2iuLCI5phOD+u qAd1ZYoZ8lf5cRiDq/yfABxmACDHLUtrCjA3wdttEIPBQQnreFKVSf5lpe2v3yBOS9bK B7Pom5U1TBRofCUJzo8vmdLPSsWKZEMNhSGKBp9ILZ3kTTDCA6bMa5qw7159hmKAoRlD UAbXFrTxeZP8uYEQ7J3lSVhgOsbnjMKFPDBMMjw7VrpHlb4rHN1Qm7NSkAFH5Y3M9I31 1sd6AkSAez7d3yQWvdCZdebuoWwD2aCcyHMeB1oCszFmB8izshEOjdRyHzhsNon4hr4B ZGJQ== X-Forwarded-Encrypted: i=1; AJvYcCVkxQfxAyzYBWhrLqf5+nCAAWdWMe8Wp34RG4Rc5uS1a/lunk+5Q+WnIPH9g9AeK798myeUEOfjMQnafjGv@lists.postgresql.org X-Gm-Message-State: AOJu0YxhgSNnrwGUlf0TNeRS77w9UxcnMr8IITXOaWhUlxKcYC41/GoW WYzzqx9ckoVyS/wXrmaCE7nbxEk7Y9B9zpRlrpzQsAkCAiglbxGMNubDbGkhEnBSyi+tnVUoECs kDfM5j4csOwDdy0p7unVJqfx5a7cpPhQ= X-Gm-Gg: AZuq6aIa/mdXuGB2xU7rz47U7HPykHxwJlCtttYcrxfL4jl5BIUTdu3yj84vYed7dRk RuECFElg8C8wozhufYTdOsNfl/k+hnSEYOhatBH1m6tkKUqnpb06RsUYnvSHxMTtXdoDmtInTNy D0h8N2O/3I51OEI9pAxaCMiq+90RC0dqWayn8VxfYZ4W6d9cToq9Mdvz4o280PO2fNN/zzlQ56h kAvw4bQ8qRPTKu8HPwYYiPqPYseC2FoZcBxdtZIfyxSwdEn0EKYi41bKjhEPrYmUj1/ll14LA== X-Received: by 2002:a05:6a00:1ac9:b0:81b:c2b5:31a with SMTP id d2e1a72fcca58-823aa721225mr11469893b3a.53.1770061043249; Mon, 02 Feb 2026 11:37:23 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Alexandra Wang Date: Mon, 2 Feb 2026 11:36:47 -0800 X-Gm-Features: AZwV_Qj1DvGU0D90qHJRrQw1l8SGcVf9D_xrQ_cf11-t7fP68TubMkTOYPBi76I Message-ID: Subject: Re: pg_plan_advice To: Robert Haas Cc: Lukas Fittl , Jacob Champion , Dian Fay , Matheus Alcantara , Jakub Wartak , PostgreSQL Hackers Content-Type: multipart/alternative; boundary="000000000000b6b7600649dc73b3" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000b6b7600649dc73b3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Robert, On Wed, Jan 28, 2026 at 9:14=E2=80=AFAM Robert Haas = wrote: > Thanks to all who have reviewed so far, and please keep it coming. I > am especially in need of more code review at this point. > Thanks for the patches! I=E2=80=99ve reviewed 0001 - 0003 so far; here are = my comments. 0001: The code looks good to me. However, I feel a bit uneasy about not seeing a test case for the additional subplan origin display added in pg_overexplain. Maybe we could add the following test cases to exercise that code: -- should show "Subplan: sub" EXPLAIN (RANGE_TABLE, COSTS OFF) SELECT * FROM vegetables v, (SELECT * FROM vegetables WHERE genus =3D 'daucus' OFFSET 0) sub; -- should show "Subplan: unnamed_subquery" EXPLAIN (RANGE_TABLE, COSTS OFF) SELECT * FROM vegetables v, (SELECT * FROM vegetables WHERE genus =3D 'daucus' OFFSET 0); 0002: Looks good to me. 0003: I see code like this: @@ -2232,6 +2251,11 @@ accumulate_append_subpath(Path *path, List **subpaths, List **special_subpaths) if (!apath->path.parallel_aware || apath->first_partial_path =3D=3D 0) { *subpaths =3D list_concat(*subpaths, apath->subpaths); + *child_append_relid_sets =3D + lappend(*child_append_relid_sets, path->parent->relids); + *child_append_relid_sets =3D + list_concat(*child_append_relid_sets, + apath->child_append_relid_sets); in accumulate_append_subpath(), but in get_singleton_append_subpath() there are only calls to lappend() and no list_concat(). Is that intentional? Do we also want to concatenate the newly pulled up child_append_relid_sets with the existing ones in get_singleton_append_subpath()? In add_paths_to_append_rel(): @@ -1785,13 +1790,16 @@ add_paths_to_append_rel(PlannerInfo *root, RelOptInfo *rel, { Path *path =3D (Path *) lfirst(l); AppendPath *appendpath; + AppendPathInput append =3D {0}; + + append.partial_subpaths =3D list_make1(path); + append.child_append_relid_sets =3D list_make1(rel->relids); Could you help me understand why we need to populate append.child_append_relid_sets here? I don=E2=80=99t see this child rel bei= ng pulled up at this point. 0004: I=E2=80=99ve only read through the README and documentation so far; I=E2=80= =99ll continue reviewing the code in 0004. Best, Alex --=20 Alexandra Wang EDB: https://www.enterprisedb.com --000000000000b6b7600649dc73b3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Robert,

On Wed, Jan 28, 2026 = at 9:14=E2=80=AFAM Robert Haas <robertmhaas@gmail.com> wrote:
Thanks to all who have reviewed so far, and please keep it coming. I
am especially in need of more code review at this point.

Thanks for the patches= ! I=E2=80=99ve reviewed 0001 - 0003 so far; here are my
comments.
0001:
The code looks good to me. However, I feel a bit uneasy about not=
seeing a test case for the additional subplan origin display added inpg_overexplain. Maybe we could add the following test cases to
exercis= e that code:

-- should show "Subplan: sub"
EXPLAIN (RAN= GE_TABLE, COSTS OFF)
SELECT * FROM vegetables v,
=C2=A0 =C2=A0 =C2=A0= =C2=A0(SELECT * FROM vegetables WHERE genus =3D 'daucus' OFFSET 0)= sub;

-- should show "Subplan: unnamed_subquery"
EXPLAI= N (RANGE_TABLE, COSTS OFF)
SELECT * FROM vegetables v,
=C2=A0 =C2=A0 = =C2=A0 =C2=A0(SELECT * FROM vegetables WHERE genus =3D 'daucus' OFF= SET 0);

0002:
Looks good to me.

0003:
I see code like t= his:

@@ -2232,6 +2251,11 @@ accumulate_append_subpath(Path *path, Li= st **subpaths, List **special_subpaths)
=C2=A0 if (!apath->path.paral= lel_aware || apath->first_partial_path =3D=3D 0)
=C2=A0 {
=C2=A0 *= subpaths =3D list_concat(*subpaths, apath->subpaths);
+ *child_append= _relid_sets =3D
+ lappend(*child_append_relid_sets, path->parent->= relids);
+ *child_append_relid_sets =3D
+ list_concat(*child_append_r= elid_sets,
+ apath->child_append_relid_sets);

in accumulate_ap= pend_subpath(), but in get_singleton_append_subpath()
there are only cal= ls to lappend() and no list_concat(). Is that
intentional? Do we also wa= nt to concatenate the newly pulled up
child_append_relid_sets with the e= xisting ones in
get_singleton_append_subpath()?

In add_paths_to_a= ppend_rel():

@@ -1785,13 +1790,16 @@ add_paths_to_append_rel(Planner= Info *root, RelOptInfo *rel,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 {
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Path =C2=A0 =C2=A0 =C2=A0 *path =3D (Path *= ) lfirst(l);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 AppendPath *appen= dpath;
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 AppendPathInput append =3D {= 0};
+
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 append.partial_subpaths = =3D list_make1(path);
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 append.child_= append_relid_sets =3D list_make1(rel->relids);

Could you help me = understand why we need to populate
append.child_append_relid_sets here? = I don=E2=80=99t see this child rel being
pulled up at this point.
0004:
I=E2=80=99ve only read through the README and documentation so fa= r; I=E2=80=99ll
continue reviewing the code in 0004.

Best,
Ale= x

--
Alexandra Wang
--000000000000b6b7600649dc73b3--