From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | Sami Imseih <samimseih(at)gmail(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:12:13 |
Message-ID: | 341357.1741201933@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> Ideally, we'd have EXPLAIN ANALYZE return two result sets, kind of like
> how a query with a semicolon returns two result sets. That changes the
> expected message flow for EXPLAIN ANALYZE, though, so we'd need a new
> option so we are sure the client is expecting it (is this a sane
> idea?).
I'm afraid not. That pretty fundamentally breaks the wire protocol,
I think. Also (1) there could be more than two, no, if the query
touches more than one foreign table? How would the client know
how many to expect? (2) there would be no particularly compelling
ordering for the multiple resultsets.
> 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 all.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2025-03-05 19:25:19 | Re: Interrupts vs signals |
Previous Message | Jeff Davis | 2025-03-05 19:00:43 | Re: explain plans for foreign servers |