From: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> |
---|---|
To: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-10-20 07:27:30 |
Message-ID: | CAFjFpRcuOkxk3DMXkRZ9rXgmbz_6iacZKvb8Zc9xRLwmK2ShgQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>
>
>> In fact, I am not in
>> favour of tracking the query dependencies for UPDATE/DELETE since we
>> don't have any concrete example as to when that would be needed.
>
>
> Right, but as I said before, some FDW might consult FDW options stored in
> those objects during AddForeignUpdateTargets, so we should do that.
>
>>> Besides
>>> that, I modified add_rte_to_flat_rtable so that the plan's dependencies
>>> are
>>> tracked, but that would lead to tracking the dependencies of unreferenced
>>> foreign tables in dead subqueries or the dependencies of foreign tables
>>> excluded from the plan by eg, constraint exclusion. But I thought that
>>> would be also OK by the same reason as above. (Another reason for that
>>> was
>>> it seemed better to me to collect the dependencies in the same place as
>>> for
>>> relation OIDs.)
>
>
>> If those unreferenced relations become references because of the
>> changes in options, we will require those query dependencies to be
>> recorded. So, if we are recording query dependencies, we should record
>> the ones on unreferenced relations as well.
>
>
> I mean plan dependencies here, not query dependencies.
A query dependency also implies plan dependency since changing query
implies plan changes. So, if query depends upon something, so does the
plan.
>
> Having said that, I like the latest version (v6), so I'd vote for marking
> this as Ready For Committer.
>
Marked that way.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
From | Date | Subject | |
---|---|---|---|
Next Message | Dilip Kumar | 2016-10-20 07:36:00 | Re: Speed up Clog Access by increasing CLOG buffers |
Previous Message | Ashutosh Bapat | 2016-10-20 07:19:35 | Re: Aggregate Push Down - Performing aggregation on foreign server |