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.
I wrote:
Also for a Foreign Scan representing a foreign join, I think "Foreign Join" is better than "Foreign Scan". Here is an example: Foreign Join on foreign_table1, foreign_table2 Remote SQL: SELECT ... FROM remote_table1 INNER JOIN remote_table2 WHERE ... I think "Foreign Join" better indicates that foreign tables listed after that (ie, foreign_table1 and foreign_table2 in the example) are joining (or component) tables of this join, than "Foreign Scan".
Postgres_fdw knows it is remote join. It is quite easy to tell the core this ForeignScan node is "Join". Also, it knows which tables are involved in.
Yeah, we can do that.
We can add hint information to control relations name to be printed.
For foreign joins, it would make sense to add such a functionality when necessary, for example when we extend the pushdown feature so that we can do what you proposed upthread.
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
