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
