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
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 |