| From: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Amit Langote <amitlangote09(at)gmail(dot)com>, 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-11-11 07:09:35 |
| Message-ID: | CAFjFpRczpw39zjE8jthQoWOhdiBpBhEa00U9xydmMYxJxd7aOw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>
> That leaves the question of whether it's worth detecting table-level
> option changes this way, or whether we should just handle those by forcing
> a relcache inval in ATExecGenericOptions, as in Amit's original patch in
> <5702298D(dot)4090903(at)lab(dot)ntt(dot)co(dot)jp>. I kind of like that approach; that
> patch was short and sweet, and it put the cost on the unusual path (ALTER
> TABLE) not the common path (every time we create a query plan).
>
You seemed not sure about this solution per [1]. Do you think we
should add similar cache invalidation when foreign server and FDW
options are modified?
> That leaves not much of this patch :-( though maybe we could salvage some
> of the test cases.
>
If that's the best way, we can add testcases to that patch.
[1] https://www.postgresql.org/message-id/29681.1459779873@sss.pgh.pa.us
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Corey Huinker | 2016-11-11 07:17:32 | Re: Do we need use more meaningful variables to replace 0 in catalog head files? |
| Previous Message | Tsunakawa, Takayuki | 2016-11-11 07:03:49 | Re: Patch: Implement failover on libpq connect level. |