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-10 08:16:22 |
Message-ID: | Y2yzVjuk945MauI7@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2022-11-10 08:17:46 | Re: Unit tests for SLRU |
Previous Message | Laurenz Albe | 2022-11-10 07:39:29 | Re: New docs chapter on Transaction Management and related changes |