On Tue, Feb 23, 2021 at 12:07 PM Andy Fan <zhihui.fan1...@gmail.com> wrote:
> 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). > Please ignore the word "RELATION_IS_OTHER_TEMP", it is pasted here by accident.. > 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/) > -- Best Regards Andy Fan (https://www.aliyun.com/)
