Re: Obsolete reference to pg_relation in comment - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Obsolete reference to pg_relation in comment
Date
Msg-id ZPjPUJBj+SVCPFfN@momjian.us
Whole thread Raw
In response to Re: Obsolete reference to pg_relation in comment  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Obsolete reference to pg_relation in comment
List pgsql-hackers
On Wed, Jul 26, 2023 at 05:14:08PM -0400, Tom Lane wrote:
> Nathan Bossart <nathandbossart@gmail.com> writes:
> > On Wed, Jul 26, 2023 at 06:48:51PM +0100, Dagfinn Ilmari Mannsåker wrote:
> >>   * All accesses to pg_largeobject and its index make use of a single Relation
> >> - * reference, so that we only need to open pg_relation once per transaction.
> >> + * reference, so that we only need to open pg_class once per transaction.
> >>   * To avoid problems when the first such reference occurs inside a
> >>   * subtransaction, we execute a slightly klugy maneuver to assign ownership of
> >>   * the Relation reference to TopTransactionResourceOwner.
> 
> > Hm.  Are you sure this is actually referring to pg_class?  It seems
> > unlikely given pg_relation was renamed 14 years before this comment was
> > added, and the code appears to be ensuring that pg_largeobject and its
> > index are opened at most once per transaction.
> 
> I believe it is just a typo/thinko for pg_class, but there's more not
> to like about this comment.  First, once we've made a relcache entry
> it would typically stay valid across uses, so it's far from clear that
> this coding actually prevents many catalog accesses in typical cases.
> Second, when we do have to rebuild the relcache entry, there's a lot
> more involved than just a pg_class fetch; we at least need to read
> pg_attribute, and I think there may be other catalogs that we'd read
> along the way, even for a system catalog that lacks complicated
> features.  (pg_index would presumably get looked at, for instance.)
> 
> I think we should reword this to just generically claim that holding
> the Relation reference open for the whole transaction reduces overhead.

How is this attached patch?

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Only you can decide what is important to you.

Attachment

pgsql-hackers by date:

Previous
From: Vik Fearing
Date:
Subject: Re: information_schema and not-null constraints
Next
From: Magnus Hagander
Date:
Subject: Release notes wording about logical replication as table owner