> On 2016/08/01 22:25, Kouhei Kaigai wrote: > > I wrote: > >>> a broader > >>> word like "Processing" seems to work well because we allow various > >>> kinds of operations to the remote side, in addition to scans/joins, > >>> to be performed in that one Foreign Scan node indicated by "Foreign > >>> Processing", such as aggregation, window functions, distinct, order > >>> by, row locking, table modification, or combinations of them. > > >> On 2016/07/29 13:28, Ashutosh Bapat wrote: > >>> "Scan" is a better word than "Processing". From plan's perspective it's > >>> ultimately a Scan (on the data produced by the foreign server) and not > >>> processing. > > I wrote: > >> Exactly, but one thing I'm concerned about is the table modification > >> case; the EXPLAIN output would be something like this: > >> > >> Foreign Scan > >> Remote SQL: INSERT INTO remote_table VALUES ... > >> > >> That would be strange, so I think a more broader word is better. I > >> don't think "Foreign Processing" is best. "Foreign Upper" might be much > >> better because the corresponding path is created by calling > >> GetForeignUpperPaths. > > > Be "Foreign %s", and gives "Insert" label by postgres_fdw; which knows > > the ForeignScan node actually insert tuples. > > From the standpoint of users, it looks "Foreign Insert". > > My concern here is EXPLAIN for foreign joins. I think it's another > problem how we handle Foreign Scan plan nodes representing > post-scan/join operations in EXPLAIN, so I'd like to leave that for > another patch. > What is the post-scan/join operations? Are you saying EPQ recheck and alternative local join plan?
Thanks, -- NEC Business Creation Division / PG-Strom Project KaiGai Kohei <kai...@ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
