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

On 2016/08/04 18:03, Kouhei Kaigai wrote:

Kaigai-san wrote:
>>> Also, the logic to print "Foreign (Scan|Insert|Update|Delete)" is different
>>> from what I suggested. I'm suggesting to allow extension giving a label
>>> to fill up "Foreign %s" format.
>>>
>>> Please explain why your choice is better than my proposition.

I wrote:
>> No, I haven't done anything about that yet.  I kept the behavior as-is.

>>> At least, my proposition is available to apply on both of foreign-scan and
>>> custom-scan, and no need to future maintenance if and when FDW gets support
>>> remote Aggregation, Sort or others.

>> I'd like to discuss this issue separately, maybe in a new thread.

> Why do you try to re-invent a similar infrastructure twice and separately?

As I said above, I haven't changed the behavior of EXPLAIN for *upper  
relation processing* such as aggregation or sorting in a ForeignScan or  
CustomScan node.

> What I proposed perfectly covers what you want to do, and has more benefits.
> - A common manner for both of ForeignScan and CustomScan
> - Flexibility to control "Foreign XXX" label and relation names to be printed.

That may be so or not, but more importantly, this is more like a user  
interface problem, so each person would have different opinions about that.

> Even if it is sufficient for the current usage of FDW, I've been saying your
> proposition is not sufficient for CustomScan nowadays, and ForeignScan in the
> near future.

Again I haven't done anything about the EXPLAIN for upper relation  
processing in both ForeignScan and CustomScan cases.  I kept the  
behavior as-is, but I don't think the behavior as-is is OK, either.

> It is not an answer to ignore the CustomScan side, because we have to enhanced
> the infrastructure of CustomScan side to follow up FDW sooner or later.
> However, we will have to apply a different manner on CustomScan side, or overwrite
> what you proposed on FDW side, at that time.
> It is not a desirable future.

I agree on that point that it's better to handle both ForeignScan and  
CustomScan cases the same way.

Best regards,
Etsuro Fujita