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

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

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

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:

Reply via email to