Re: explain plans for foreign servers

Hi,

On Wed, Aug 5, 2026 at 3:48 AM Dinesh Salve <cooltodinesh(at)gmail(dot)com> wrote:
>
> Thanks for the inputs, attached v7 patch to make review easier.

Thanks for the patch.

I have a couple of design questions before proceeding with the patch review.

+ /*
+ * The deparsed SQL may contain $n placeholders, which a plain remote
+ * EXPLAIN cannot plan: it fails with "there is no parameter $1". We
+ * therefore force GENERIC_PLAN, which is only available from PG 16.
+ */

I understand that reasoning, but why always enforce GENERIC_PLAN? When
there are no placeholders in the query, sending it seems fine but
unnecessary. I looked at the code comment around fdw_exprs in
postgresGetForeignPlan() and it looks like when there are placeholders
it would tell us that. Can we use that to skip enforcing the option
when there are none? Am I missing something? Was this discussed
upthread?

> > Another point, why are we not supporting explain analyze?
> This will be part of follow-up work, I wanted agreement on the shape first from the community.
> One design I considered is an auto_explain-style GUC asking the remote to emit the plan for the statement it is already
> running, but we cannot assume an arbitrary foreign server has that, so it needs a fallback and more thought.

Having the remote EXPLAIN support first makes sense. However, having a
high-level design for EXPLAIN ANALYZE support would make the feature
more concrete. IIUC, is the difficulty here that since GENERIC_PLAN is
always enforced and it is mutually exclusive with ANALYZE, it makes it
harder? Am I missing something? Are there any other issues?

--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com