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