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
