Hi, On Wed, Aug 5, 2026 at 3:48 AM Dinesh Salve <[email protected]> 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
