| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
| Cc: | 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. |
| Date: | 2016-04-04 14:24:33 |
| Message-ID: | 29681.1459779873@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2016-04-04 14:48:56 | Re: Tiny patch: sigmask.diff |
| Previous Message | Teodor Sigaev | 2016-04-04 14:14:22 | Re: WIP: Covering + unique indexes. |