On 2016/09/29 20:06, Ashutosh Bapat wrote:
On Wed, Aug 24, 2016 at 1:55 PM, Etsuro Fujita
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.
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: