Re: Foreign join pushdown vs EvalPlanQual

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

On 2015/08/27 16:52, Kouhei Kaigai wrote:
I wrote:
>> I don't understand what you proposed,

> What I'm talking about is philosophy of software/interface design.
> I understand EPQ recheck by alternative plan is "one" reasonable way,
> however, people often have different ideas and may be better than
> your idea depending on its context/environment/prerequisites/etc...
> It is always unpredictable, only God can know what is the best solution.
>
> In other words, I didn't talk about taste of restaurant, the problem is
> lack of variation on the menu. You may not want, but we have freedom to
> eat terrible taste meal.

>> but ISTM that your proposal is
>> more like a feature, rather than a bugfix.

> Yes, the problem we are facing is lack of a feature. It might be my
> oversight when I designed join pushdown infrastructure. Sorry.
> So, it is quite natural to add the missing piece to fix up the bug.

>> For what you proposed, I
>> think we should also improve the existing EPQ mechanism including the
>> corresponding FDW routines. One possible improvement is the behavior of
>> late row locking. Currently, we do that by 1) re-fetching each
>> component tuple from the foreign table after locking it by
>> RefetchForeignRow and then 2) if necessary, doing an EPQ recheck, ie,
>> re-running the query locally for such component tuples by the core. So,
>> if we could re-run the join part of the query remotely without
>> tranferring such component tuples from the foreign tables, we would be
>> able to not only avoid useless data transfer but improve concurrency
>> when the join fails.
>>
>> So, how about addressing this issue in two steps; first, work on the
>> bugfix patch in [1], and then, work on what you propsed. The latter
>> would need more discussion/work, so I think it would be better to take
>> that in 9.6. If it's OK, I'll update the patch in [1] and add it to the
>> upcoming CF.

> It seems to me too invasive for bugfix, and assumes a particular solution.
> Please do the rechecking part in the extension, not in the core.

I think we would probably need others' opinions about this issue.

Best regards,
Etsuro Fujita

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Shulgin, Oleksandr 2015-08-27 09:54:08 Re: psql - better support pipe line
Previous Message Kouhei Kaigai 2015-08-27 07:52:05 Re: Foreign join pushdown vs EvalPlanQual