|From:||Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>|
|To:||Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>|
|Cc:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Rajkumar Raghuwanshi <rajkumar(dot)raghuwanshi(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: postgres_fdw : altering foreign table not invalidating prepare statement execution plan.|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 2016/09/29 20:06, Ashutosh Bapat wrote:
> On Wed, Aug 24, 2016 at 1:55 PM, Etsuro Fujita
> <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)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
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.
|Next Message||Etsuro Fujita||2016-09-29 12:51:58||Re: postgres_fdw : altering foreign table not invalidating prepare statement execution plan.|
|Previous Message||Etsuro Fujita||2016-09-29 12:12:30||Re: Push down more full joins in postgres_fdw|