Stephen Frost <sfr...@snowman.net> writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> 2. Wedging this into EXPLAIN would be quite ugly, because (at least >> as I envision it) the output would have just about nothing to do with >> any existing EXPLAIN output.
> This is a better argument for not making it part of EXPLAIN, though I > don't really feel like I've got a decent idea of what you are suggesting > the output *would* look like, so it's difficult for me to agree (or > disagree) about this particular point. Per postgres_fdw's get_remote_estimate(), the only data we use right now is the startup_cost, total_cost, rows and width estimates from the top-level Plan node. That's available immediately from the Plan tree, meaning that basically *nothing* of the substantial display effort expended by explain.c and ruleutils.c is of any value. So the level-zero implementation of this would be to run the parser and planner, format those four numbers into a JSON object (which would require little more infrastructure than sprintf), and return that. Sure, we could make that into some kind of early-exit path in explain.c, but I think it'd be a pretty substantial wart, especially since it'd mean that none of the other EXPLAIN options are sensible in combination with this one. Further down the road, we might want to rethink the whole idea of completely constructing a concrete Plan. We could get the data we need at the list-of-Paths stage. Even more interesting, we could (with very little more work) return data about multiple Paths, so that the client could find out, for example, the costs of sorted and unsorted output without paying two network round trips to discover that. That'd definitely require changes in the core planner, since it has no API to stop at that point. And it's even less within the charter of EXPLAIN. I grant your point that there might be other users for this besides postgres_fdw, but that doesn't mean it must be a core feature. >> 3. We surely would not back-patch a core change like this. OTOH, if >> the added infrastructure is in an extension, somebody might want to >> back-patch that (even if unofficially). > Since postgres_fdw is part of core and core's release cycle, and the > packagers manage the extensions from core in a way that they have to > match up, this argument doesn't hold any weight with me. Certainly only v14 (or whenever) and later postgres_fdw would be able to *use* this data. The scenario I'm imagining is that somebody wants to be able to use that client against an older remote server, and is willing to install some simple extension on the remote server to do so. Perhaps this scenario is not worth troubling over, but I don't think it's entirely far-fetched. regards, tom lane