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

From: Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>
To: Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>
Cc: 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-08-01 11:25:59
Message-ID: 893f6de7-2406-accc-5806-b4a5210ce690@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2016/07/29 13:28, Ashutosh Bapat wrote:

I wrote:
> Probably something like this:
>
> Foreign Processing
> Remote Operations: ...
>
> In the Remote Operations line, the FDW/extension could print
> any info
> about remote operations, eg, "Scan/Join + Aggregate".

I wrote:
> I intentionally chose that word and thought we could leave detailed
> descriptions about remote operations to the FDW/extension; a broader
> word like "Processing" seems to work well because we allow various
> kinds of operations to the remote side, in addition to scans/joins,
> to be performed in that one Foreign Scan node indicated by "Foreign
> Processing", such as aggregation, window functions, distinct, order
> by, row locking, table modification, or combinations of them.

> "Scan" is a better word than "Processing". From plan's perspective it's
> ultimately a Scan (on the data produced by the foreign server) and not
> processing.

Exactly, but one thing I'm concerned about is the table modification
case; the EXPLAIN output would be something like this:

Foreign Scan
Remote SQL: INSERT INTO remote_table VALUES ...

That would be strange, so I think a more broader word is better. I
don't think "Foreign Processing" is best. "Foreign Upper" might be much
better because the corresponding path is created by calling
GetForeignUpperPaths.

Also for a Foreign Scan representing a foreign join, I think "Foreign
Join" is better than "Foreign Scan". Here is an example:

Foreign Join on foreign_table1, foreign_table2
Remote SQL: SELECT ... FROM remote_table1 INNER JOIN remote_table2
WHERE ...

I think "Foreign Join" better indicates that foreign tables listed after
that (ie, foreign_table1 and foreign_table2 in the example) are joining
(or component) tables of this join, than "Foreign Scan".

Best regards,
Etsuro Fujita

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Bapat 2016-08-01 11:31:35 Re: Oddity in EXPLAIN for foreign/custom join pushdown plans
Previous Message Dean Rasheed 2016-08-01 11:24:15 Re: Combining hash values