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
