(2014/12/07 2:02), David Fetter wrote:
On Thu, Dec 04, 2014 at 12:35:54PM +0900, Etsuro Fujita wrote:
But I think
there would be another idea. An example will be shown below. We show the
update commands below the ModifyTable node, not above the corresponding
ForeignScan nodes, so maybe less confusing. If there are no objections of
you and others, I'll update the patch this way.
postgres=# explain verbose update parent set a = a * 2 where a = 5;
QUERY PLAN
-------------------------------------------------------------------------------------
Update on public.parent (cost=0.00..280.77 rows=25 width=10)
On public.ft1
Remote SQL: UPDATE public.mytable_1 SET a = $2 WHERE ctid = $1
^^^^^^^^^^
It occurs to me that the command generated by the FDW might well not
be SQL at all, as is the case with file_fdw and anything else that
talks to a NoSQL engine.
Would it be reasonable to call this "Remote command" or something
similarly generic?
Yeah, but I'd like to propose that this line is shown by the FDW API
(ie, ExplainForeignModify) as in non-inherited update cases, so that the
FDW developer can choose the right name. As for "On public.ft1", I'd
like to propose that the FDW API also show that by calling a function
for that introduced into the PG core (Would it be better to use "For"
rather than "On"?).
Sorry, my explanation was not enough.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
