On 2016/04/04 23:24, Tom Lane wrote:
Amit Langote <langote_amit...@lab.ntt.co.jp> writes:
On 2016/04/04 15:17, Rajkumar Raghuwanshi wrote:
* .Observation: *Prepare statement execution plan is not getting changed
even after altering foreign table to point to new schema.
I wonder if performing relcache invalidation upon ATExecGenericOptions()
is the correct solution for this problem. The attached patch fixes the
issue for me.
A forced relcache inval will certainly fix it, but I'm not sure if that's
the best (or only) place to put it.
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.
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: