On 2016/09/29 20:06, Ashutosh Bapat wrote:
> On Wed, Aug 24, 2016 at 1:55 PM, Etsuro Fujita
> <fujita.etsuro@lab.ntt.co.jp> wrote:
>> On 2016/04/04 23:24, Tom Lane wrote:
>>> A related issue, now that I've seen this example, is that altering
>>> FDW-level or server-level options won't cause a replan either. I'm
>>> not sure there's any very good fix for that. Surely we don't want
>>> to try to identify all tables belonging to the FDW or server and
>>> issue relcache invals on all of them.
>> While improving join pushdown in postgres_fdw, I happened to notice that the
>> fetch_size option in 9.6 has the same issue. A forced replan discussed
>> above would fix that issue, but I'm not sure that that's a good idea,
>> because the fetch_size option, which postgres_fdw gets at GetForeignRelSize,
>> is not used for anything in creating a plan. So, as far as the fetch_size
>> option is concerned, a better solution is (1) to consult that option at
>> execution time, probably at BeginForeignScan, not at planning time such as
>> GetForiegnRelSize (and (2) to not cause that replan when altering that
>> option.) Maybe I'm missing something, though.
> As explained in my latest patch, an FDW knows which of the options,
> when changed, render a plan invalid. If we have to track the changes
> for each option, an FDW will need to consulted to check whether that
> options affects the plan or not. That may be an overkill and there is
> high chance that the FDW authors wouldn't bother implementing that
> hook.
I thought it would be better to track that dependencies to avoid useless
replans, but I changed my mind; I agree with Amit's approach. In
addition to what you mentioned, ISTM that users don't change such
options frequently, so I think Amit's approach is much practical.
> Let me know your views on my latest patch on this thread.
OK, will do.
Best regards,
Etsuro Fujita
