Re: Avoid overhead open-close indexes (catalog updates)

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
Cc: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Avoid overhead open-close indexes (catalog updates)
Date: 2022-11-15 21:58:01
Message-ID: Y3QLaWvU6NCoy/ZW@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Nov 15, 2022 at 11:42:34AM -0300, Ranier Vilela wrote:
> I find it very difficult not to have some tuple to be updated,
> once inside CopyStatistics and the branch cost can get in the way,
> but I don't object with your solution.

The code assumes that it is a possibility.

> Missed AddRoleMems?
> Could you continue with CatalogTupleInsertWithInfo, what do you think?

This one has been left out on purpose. I was tempting to use
WithInfo() with a CatalogIndexState opened optionally but I got the
impression that it makes the code a bit harder to follow and
AddRoleMems() is already complex on its own. Most DDL patterns
working on role would involve one role. More roles could be added of
course in one shot, but the extra logic complexity did not look that
appealing to me especially as some role updates are skipped.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2022-11-15 21:58:10 Re: Add palloc_aligned() to allow arbitrary power of 2 memory alignment
Previous Message Peter Geoghegan 2022-11-15 21:54:24 Re: Standardizing how pg_waldump presents recovery conflict XID cutoffs