Re: Foreign join pushdown vs EvalPlanQual

From: Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, 花田茂 <shigeru(dot)hanada(at)gmail(dot)com>
Subject: Re: Foreign join pushdown vs EvalPlanQual
Date: 2015-09-11 03:36:26
Message-ID: 55F24C3A.7090500@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2015/09/11 6:24, Robert Haas wrote:
> On Thu, Sep 3, 2015 at 1:22 AM, Etsuro Fujita
> <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>>> I'm wondering if there's another approach. If I understand correctly,
>>> there are two reasons why the current situation is untenable. The
>>> first is that ForeignRecheck always returns true, but we could instead
>>> call an FDW-supplied callback routine there. The callback could be
>>> optional, so that we just return true if there is none, which is nice
>>> for already-existing FDWs that then don't need to do anything.
>>
>> My question about this is, is the callback really needed? If there are any
>> FDWs that want to do the work *in their own way*, instead of just doing
>> ExecProcNode for executing a local join execution plan in case of foreign
>> join (or just doing ExecQual for checking remote quals in case of foreign
>> table), I'd agree with introducing the callback, but if not, I don't think
>> that that makes much sense.
>
> It doesn't seem to me that it hurts much of anything to add the
> callback there, and it does provide some flexibility. Actually, I'm
> not really sure why we're thinking we need a subplan here at all,
> rather than just having a ForeignRecheck callback that can do whatever
> it needs to do with no particular help from the core infrastructure.
> I think you wrote some code to show how postgres_fdw would use the API
> you are proposing, but I can't find it. Can you point me in the right
> direction?

I've proposed the following API changes:

* I modified create_foreignscan_path, which is called from
postgresGetForeignJoinPaths/postgresGetForeignPaths, so that a path,
subpath, is passed as the eighth argument of the function. subpath
represents a local join execution path if scanrelid==0, but NULL if
scanrelid>0.

* I modified make_foreignscan, which is called from
postgresGetForeignPlan, so that a list of quals, fdw_quals, is passed as
the last argument of the function. fdw_quals represents remote quals if
scanrelid>0, but NIL if scanrelid==0.

You can find that code in the postgres_fdw patch
(foreign_join_v16_efujita.patch) attached to [1].

Best regards,
Etsuro Fujita

[1] http://www.postgresql.org/message-id/55CB2D45.7040100@lab.ntt.co.jp

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro HORIGUCHI 2015-09-11 04:37:55 Parser emits mysterious error message for very long tokens
Previous Message Etsuro Fujita 2015-09-11 02:33:39 Re: Another typo in comment in setrefs.c