Re: Replacing pg_depend PIN entries with a fixed range check - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Replacing pg_depend PIN entries with a fixed range check
Date
Msg-id 20210416000547.qgbmrvdxhezmzrsu@alap3.anarazel.de
Whole thread Raw
In response to Re: Replacing pg_depend PIN entries with a fixed range check  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Replacing pg_depend PIN entries with a fixed range check  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi,

On 2021-04-15 19:59:24 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > Hm, maybe we ought to swap template0 and template1 instead? I.e. have
> > template0 be in pg_database.dat and thus get a pinned oid, and then
> > create template1, postgres etc from that?
> 
> No, *neither* of them are pinned, and we don't want them to be.
> It's something of a historical artifact that template1 has a low OID.

Hm, it makes sense for template1 not to be pinned, but it doesn't seem
as obvious why that should be the case for template0.


> In short, I'm really skeptical of changing any of these pin-or-not
> decisions to save one or two comparisons in IsPinnedObject.  That
> function is already orders of magnitude faster than what it replaces;
> we don't need to sweat over making it faster yet.

I'm not at all concerned about the speed after the change - it just
seems cleaner and easier to understand not to have exceptions.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?)
Next
From: Tom Lane
Date:
Subject: Re: Replacing pg_depend PIN entries with a fixed range check