On 2016/07/27 13:51, Kouhei Kaigai wrote:
This output is, at least, not incorrect.
This ForeignScan actually scan a relation that consists of two joined
tables on the remote side. So, not incorrect, but may not convenient for
better understanding by users who don't have deep internal knowledge.


Hmm.

On the other hands, I cannot be happy with your patch because it concludes
the role of ForeignScan/CustomScan with scanrelid==0 is always join.
However, it does not cover all the case.

When postgres_fdw gets support of remote partial aggregate, we can implement
the feature using ForeignScan with scanrelid==0. Is it a join? No.

Yeah, I think that that could be implemented in both cases (scanrelid>0 and scanrelid=0).

Probably, the core cannot know exact purpose of ForeignScan/CustomScan with
scanrelid==0. It can be a remote partial aggregation. It can be an alternative
sort logic by GPU. It can be something others.
So, I think extension needs to inform the core more proper label to show;
including a flag to control whether the relation(s) name shall be attached
next to the ForeignScan/CustomScan line.

I'd like you to suggest to add two fields below:
 - An alternative label extension wants to show instead of the default one

How about adding something like the "Additional Operations" line as proposed in a previous email, instead? As you know, FDWs/Extensions could add such information through ExplainForeignScan/ExplainCustomScan.

 - A flag to turn on/off printing relation(s) name

ISTM that the relation information should be always printed even in the case of scanrelid=0 by the core, because that would be essential for analyzing EXPLAIN results.

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

Reply via email to