Re: explain plans for foreign servers

From: Sami Imseih <samimseih(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, dinesh salve <cooltodinesh(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: explain plans for foreign servers
Date: 2025-03-05 19:26:15
Message-ID: CAA5RZ0uPt13vOirJ4-__HFT0QSZNEmSS_szYii_Aimc=yBDHEw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>> What if we do something like a new EXPLAIN option which returns all
>> the rows
>> back to the client, and then writes out the plan to some local
>> memory.

> That's another idea, but I am starting to think returning two result
> sets from EXPLAIN ANALYZE would be generally useful.

I did not think that would be doable. Because a
ForeignScanNode for postgres_fdw is a DECLARE CURSOR
followed by a serious of FETCH statements and finally a CLOSE,
I suspect we can store the plan in memory when the cursor is closed
and then it's up to the fdw to call a remote sql to fetch the plan to the
other side to append it on top of the explain output.

I also thought about 2 options 1/ new EXPLAIN option to do this -or-
2/ put in core GUCs to allow storing the last plan in memory at
ExecutorEnd.

>> I wonder if Robert's extensible EXPLAIN work[1] could be useful
>> here?

> I'm wondering the same. You could certainly imagine cramming
> all of the foreign EXPLAIN output into some new field attached
> to the ForeignScan node. Readability and indentation would
> require some thought, but the other approaches don't have any
> mechanism for addressing that at al

FWIW, I had the same thought [0] and planned on doing the investigation.

[0] https://www.postgresql.org/message-id/CAA5RZ0tLrNOw-OgPkv49kbNmZS4nFn9vzpN5HXX_xvOaM9%3D5ww%40mail.gmail.com

--
Sami Imseih

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Florents Tselai 2025-03-05 19:29:50 Re: PATCH: jsonpath string methods: lower, upper, initcap, l/r/btrim, replace, split_part
Previous Message Andres Freund 2025-03-05 19:25:19 Re: Interrupts vs signals