Re: postgres_fdw : altering foreign table not invalidating prepare statement execution plan.

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