Re: postgres_fdw : altering foreign table not invalidating prepare statement execution plan.
От | Etsuro Fujita |
---|---|
Тема | Re: postgres_fdw : altering foreign table not invalidating prepare statement execution plan. |
Дата | |
Msg-id | bc36fdca-d26d-b134-f5f7-5017c2f7b431@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: postgres_fdw : altering foreign table not invalidating prepare statement execution plan. (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>) |
Список | pgsql-hackers |
On 2016/10/20 16:27, Ashutosh Bapat wrote: I wrote: >>>> 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. You wrote: >>> 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 wrote: >> 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. Right. Sorry, my explanation was not enough, but what I just wanted to mention is: for unreferenced relations in the plan (eg, foreign tables excluded from the plan by constraint exclusion), we don't need to record the dependencies of those relations on FDW-related objects in the plan dependency list (ie, glob->invalItems), because the changes to attributes of the FDW-related objects for those relations wouldn't affect the plan. I wrote: >> Having said that, I like the latest version (v6), so I'd vote for marking >> this as Ready For Committer. > Marked that way. Thanks! Best regards, Etsuro Fujita
В списке pgsql-hackers по дате отправления: