Re: pg_temp_%d namespace creation can invalidate all the cached plan in other backends

On Tue, Feb 23, 2021 at 12:07 PM Andy Fan <zhihui(dot)fan1213(at)gmail(dot)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/)