Planning is expensive and we use plancache to bypass its effect. I find the $subject recently which is caused by we register NAMESPACEOID invalidation message for pg_temp_%s as well as other normal namespaces. Is it a must?
We can demo the issue with the below case: Sess1: create table t (a int); prepare s as select * from t; postgres=# execute s; INFO: There is no cached plan now a --- (0 rows) postgres=# execute s; -- The plan is cached. a --- (0 rows) Sess2: create temp table m (a int); Sess1: postgres=# execute s; -- The cached plan is reset. INFO: There is no cached plan now a --- (0 rows) What I want to do now is bypass the invalidation message totally if it is a pg_temp_%d namespace. (RELATION_IS_OTHER_TEMP). With this change, the impact is not only the plan cache is not reset but also all the other stuff in SysCacheInvalidate/CallSyscacheCallbacks will not be called (for pg_temp_%d change only). I think pg_temp_%d is not meaningful for others, so I think the bypassing is OK. I still have not kicked off any coding so far, I want to know if it is a correct thing to do? -- Best Regards Andy Fan (https://www.aliyun.com/)
