From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Petr Jelinek <petr(at)2ndquadrant(dot)com>, Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: WIP: Upper planner pathification |
Date: | 2016-03-14 17:37:32 |
Message-ID: | 4419.1457977052@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Mar 14, 2016 at 1:04 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> It would be better if we invent an FDW callback that's meant to be
>> invoked at this stage, but only call it for FDW(s) actively involved
>> in the query. I'm not sure exactly what that ought to look like though.
>> Maybe only call the FDW identified as possible owner of the topmost
>> scan/join relation?
> I think in the short term that's as well as we're going to do, so +1.
> In the long run, I'm interested in making FDWs be able to optimize
> queries like foreigntab JOIN localtab ON foreigntab.x = localtab.x
> (e.g. by copying localtab to the remote side when it's small); but
> that will require revisiting some old decisions, too.
Yeah. An alternative definition that would support that would be to
call the upper-path-providing callback for each FDW that's responsible
for any base relation of the query. But I think that that would often
lead to a lot of redundant/wasted computation, and it's not clear to
me that we can support such cases without other changes as well.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-03-14 17:39:01 | Re: amcheck (B-Tree integrity checking tool) |
Previous Message | Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?= | 2016-03-14 17:31:27 | Re: [PATCH] Use correct types and limits for PL/Perl SPI query results |