Re: Hooking at standard_join_search (Was: Re: Foreign join pushdown vs EvalPlanQual)

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>, 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: Hooking at standard_join_search (Was: Re: Foreign join pushdown vs EvalPlanQual)
Date: 2015-09-08 20:18:12
Message-ID: CA+Tgmob_NuKe30i63pmg-9mje3EyC8EisgZT_3GBXPDZPUWf8Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Sep 3, 2015 at 11:51 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Wed, Sep 2, 2015 at 1:47 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Offhand I think that the
>>> most likely way to build that text will be to examine the query's jointree
>>> to see where c,d,e appear in it. But in any case, that's a separate issue
>>> and I fail to see how plopping the join search problem into the FDW's lap
>>> would make it any easier.
>
>> Yeah, I am not advocating for putting the hook in
>> standard_join_search. I'm explaining why I put it in
>> add_paths_to_joinrel instead of, as I believe you were advocating, in
>> make_join_rel prior to the big switch.
>
> If you had a solution to the how-to-build-the-query-text problem,
> and it depended on that hook placement, then your argument might
> make some sense. As is, you've entirely failed to convince me
> that this placement is not wrong, wasteful, and likely to create
> unnecessary API breaks for FDWs.
>
> (Also, per my last message on the subject, *after* the switch
> is what I think makes sense.)

After re-reading a few emails, I've realized that I've let myself get
a bit confused here and have unwittingly switched sides in this
argument. <puts brown paper bag over head>

When we originally discussed this back in April, I was arguing for
either make_join_rel() or add_paths_to_joinrel() and you were arguing
for standard_join_search(). See here:

http://www.postgresql.org/message-id/CA+TgmobOADxTbsCt-j+dDVefWGK1WxY4p8AVDp1Pz48_TX4XTA@mail.gmail.com

I thought we were still having the same argument, but we're not.
You're now arguing for make_one_rel(), which back then was perfectly
acceptable to me, and now that I've gotten by thinking un-fuzzed,
really still is, except for the question posed in the closing
paragraph of that email, which is (mostly) whether clients like
postgres_fdw are going to need extra_lateral_rels in order to do the
right thing.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2015-09-08 20:21:12 Re: exposing pg_controldata and pg_config as functions
Previous Message Robbie Harwood 2015-09-08 19:12:49 Re: [PATCH v2] GSSAPI encryption support