|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 2015/08/27 16:52, Kouhei Kaigai 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 , 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  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.
|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|