Re: explain plans for foreign servers
Sami Imseih <samimseih@gmail.com>
From: Sami Imseih <samimseih@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Jeff Davis <pgsql@j-davis.com>, dinesh salve <cooltodinesh@gmail.com>, pgsql-hackers@postgresql.org
Date: 2025-03-05T19:26:15Z
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