Etsuro Fujita <fujita.ets...@lab.ntt.co.jp> writes: > [ foreign_plan_cache_inval_v6.patch ]
I looked through this a bit. A point that doesn't seem to have been discussed anywhere in the thread is why foreign tables should deserve exact tracking of dependencies, when we have not bothered with that for most other object types. Schemas, for example, we're happy to just zap the whole plan cache for. Attempting to do exact tracking is somewhat expensive and bug-prone --- the length of this thread speaks to the development cost and bug hazard. Meanwhile, nobody has questioned the cost of attaching more PlanInvalItems to a plan (and the cost of the extra catalog lookups this patch does to create them). For most plans, that's nothing but overhead because no invalidation will actually occur in the life of the plan. I think there's a very good argument that we should just treat any inval in pg_foreign_data_wrapper as a reason to blow away the whole plan cache. People aren't going to alter FDW-level options often enough to make it worth tracking things more finely. Personally I'd put pg_foreign_server changes in the same boat, though maybe those are changed slightly more often. If it's worth doing anything more than that, it would be to note which plans mention foreign tables at all, and not invalidate those that don't. We could do that with, say, a hasForeignTables bool in PlannedStmt. 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.4090...@lab.ntt.co.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). That leaves not much of this patch :-( though maybe we could salvage some of the test cases. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers