Re: Foreign join pushdown vs EvalPlanQual
От | Etsuro Fujita |
---|---|
Тема | Re: Foreign join pushdown vs EvalPlanQual |
Дата | |
Msg-id | 55DECAA3.2070809@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: Foreign join pushdown vs EvalPlanQual (Kouhei Kaigai <kaigai@ak.jp.nec.com>) |
Ответы |
Re: Foreign join pushdown vs EvalPlanQual
|
Список | 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
В списке pgsql-hackers по дате отправления: