Re: Oddity in EXPLAIN for foreign/custom join pushdown plans

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