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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
