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.