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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pg_temp_%d namespace creation can invalidate all the cached plan in other backends
Date: 2021-02-23 05:50:41
Message-ID: 3795551.1614059441@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com> writes:
> 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?

Since we don't normally delete those namespaces once they exist,
the number of such events is negligible over the life of a database
(at least in production scenarios). I'm having a very hard time
getting excited about spending effort here.

Also, you can't just drop the inval event, because even if you
believe it's irrelevant to other backends (a questionable
assumption), it certainly is relevant locally.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2021-02-23 06:03:12 Re: pgsql: pg_collation_actual_version() -> pg_collation_current_version().
Previous Message Tom Lane 2021-02-23 05:43:47 Re: Hybrid Hash/Nested Loop joins and caching results from subplans