| From: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
|---|---|
| To: | 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 08:45:01 |
| Message-ID: | 5702298D.4090903@lab.ntt.co.jp |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
Thanks for the report.
On 2016/04/04 15:17, Rajkumar Raghuwanshi wrote:
> Hi,
>
> I observed below in postgres_fdw
>
> * .Observation: *Prepare statement execution plan is not getting changed
> even after altering foreign table to point to new schema.
>
[ ... ]
> PREPARE stmt_ft AS select c1,c2 from ft;
>
> EXECUTE stmt_ft;
> c1 | c2
> ----+-------
> 1 | s1.lt
> (1 row)
>
> --changed foreign table ft pointing schema from s1 to s2
> ALTER foreign table ft options (SET schema_name 's2', SET table_name 'lt');
> ANALYZE ft;
>
> EXPLAIN (COSTS OFF, VERBOSE) EXECUTE stmt_ft;
> QUERY PLAN
> ----------------------------------------
> Foreign Scan on public.ft
> Output: c1, c2
> Remote SQL: SELECT c1, c2 FROM s1.lt
> (3 rows)
I wonder if performing relcache invalidation upon ATExecGenericOptions()
is the correct solution for this problem. The attached patch fixes the
issue for me.
Thanks,
Amit
| Attachment | Content-Type | Size |
|---|---|---|
| cache-inval-ft-options-1.patch | text/x-diff | 662 bytes |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2016-04-04 08:58:31 | Re: Move PinBuffer and UnpinBuffer to atomics |
| Previous Message | Fujii Masao | 2016-04-04 08:28:07 | Re: Support for N synchronous standby servers - take 2 |