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
