Re: postgres_fdw : altering foreign table not invalidating prepare statement execution plan.
От | Ashutosh Bapat |
---|---|
Тема | Re: postgres_fdw : altering foreign table not invalidating prepare statement execution plan. |
Дата | |
Msg-id | CAFjFpRcuOkxk3DMXkRZ9rXgmbz_6iacZKvb8Zc9xRLwmK2ShgQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: postgres_fdw : altering foreign table not invalidating prepare statement execution plan. (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>) |
Ответы |
Re: postgres_fdw : altering foreign table not invalidating
prepare statement execution plan.
|
Список | 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
В списке pgsql-hackers по дате отправления: