Re: Obsolete reference to pg_relation in comment
От | Bruce Momjian |
---|---|
Тема | Re: Obsolete reference to pg_relation in comment |
Дата | |
Msg-id | ZPjPUJBj+SVCPFfN@momjian.us обсуждение исходный текст |
Ответ на | Re: Obsolete reference to pg_relation in comment (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Obsolete reference to pg_relation in comment
|
Список | 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.
Вложения
В списке pgsql-hackers по дате отправления: