From: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Oddity in EXPLAIN for foreign/custom join pushdown plans |
Date: | 2016-07-27 08:55:42 |
Message-ID: | 5847f454-54e2-ad6a-a28d-dcbc60412cd4@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Dean Rasheed | 2016-07-27 08:57:47 | Re: Optimizing numeric SUM() aggregate |
Previous Message | Etsuro Fujita | 2016-07-27 08:50:32 | Re: Oddity in EXPLAIN for foreign/custom join pushdown plans |