Re: Avoid overhead open-close indexes (catalog updates)
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Ranier Vilela <ranier.vf@gmail.com>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, pgsql-hackers@postgresql.org
Date: 2022-11-10T08:16:22Z
Lists: pgsql-hackers
On Thu, Sep 01, 2022 at 08:42:15AM -0300, Ranier Vilela wrote: > Let's wait for the patch to be accepted and committed, so we can try to > change it. FWIW, I think that this switch is a good idea for cases where we potentially update a bunch of tuples, especially based on what CatalogTupleInsert() tells in its top comment. Each code path updated here needs a performance check to see if that's noticeable enough, but I can get behind the one of CopyStatistics(), at least. EnumValuesCreate() would matter less as this would require a large set of values in an enum, but perhaps ORMs would care and that should be measurable. update_attstats() should lead to a measurable difference with a relation that has a bunch of attributes with few tuples. DefineTSConfiguration() is less of an issue, still fine to change. AddRoleMems() should be equally measurable with a large DDL. As a whole, this looks pretty sane to me and a good idea to move on with. I still need to check properly the code paths changed here, of course.. -- Michael
Commits
-
Use multi-inserts for pg_ts_config_map
- 63c833f4bdca 16.0 landed
-
Use multi-inserts for pg_enum
- 1ff416121884 16.0 landed
-
Avoid some overhead with open and close of catalog indexes
- 09a72188cd5c 16.0 landed
-
Preserve index data in pg_statistic across REINDEX CONCURRENTLY
- b17ff07aa3eb 14.0 cited