Re: pg_plan_advice fails on a CustomScan that replaces a join

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Dongpo Liu <poe(dot)liu(at)pm(dot)me>
Cc: "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Noah Misch <noah(at)leadboat(dot)com>
Subject: Re: pg_plan_advice fails on a CustomScan that replaces a join
Date: 2026-11-03 15:31:43
Message-ID: CA+Tgmobdw-aEksh-HoteGNpTbbsq7V7bUi5ufN5FNmNvPXuWPw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Oct 5, 2026 at 4:23 AM Dongpo Liu <poe(dot)liu(at)pm(dot)me> wrote:
> The attached patch makes pgpa_relids() return custom_relids, in the
> same way as fs_relids for a ForeignScan.

Thanks. Committed and back-patched to v19. I strongly suspect that
there are more problems in this area, many of which will probably
require more redesign than is practical for v19, but that's not a
reason not to commit simple fixes that move the needle, and this seems
to fall into that category.

Longer term, I think we should consider giving names to custom scan
providers, and finding some way to let advice specify one. For
example, CUSTOM_SCAN cjoin ((foo bar)) could mean "use the cjoin
provider to join foo and bar. The exact syntax is open to
bikeshedding. Foreign joins might merit similar treatment, but it
seems less clear, because presumably only one foreign scan provider is
eligible to handle an given scan or join.

> The patch has no regression test, because a test needs a custom scan
> provider that replaces a join. src/test/modules/test_extensible
> (0e944fe3579) has a provider now, but only for a scan of one table.
> Would it be acceptable to add a join mode to it for such a test? I
> can write that.

I don't know of a reason why that wouldn't be acceptable. I'd just
caution that you should think about how much energy you're willing to
put into this. Making everything work nicely for plan advice with
custom scans is probably a significant amount of work, which is why I
didn't do it. I'm happy to have someone else pick it up, but we'll
probably need to draw a line somewhere in terms of what we can
back-patch into v19, and target anything beyond that at v20 or later.

--
Robert Haas
Databricks

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2026-11-03 15:34:36 -Wcast-qual home stretch
Previous Message Raja Sai pranav 2026-11-03 15:17:41 Re: Re: Offline data checksum changes can cause incorrect checksum state on standbys