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

Поиск
Список
Период
Сортировка
Искать
От
Michael Paquier
Тема
Re: Avoid overhead open-close indexes (catalog updates)
Дата
Msg-id
Y2yzVjuk945MauI7@paquier.xyz
Ответ на
Список
Дерево обсуждения
Avoid overhead open-close indexes (catalog updates) Ranier Vilela <ranier.vf@gmail.com>
Re: Avoid overhead open-close indexes (catalog updates) Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Re: Avoid overhead open-close indexes (catalog updates) Ranier Vilela <ranier.vf@gmail.com>
Re: Avoid overhead open-close indexes (catalog updates) Michael Paquier <michael@paquier.xyz>
Re: Avoid overhead open-close indexes (catalog updates) Ranier Vilela <ranier.vf@gmail.com>
Re: Avoid overhead open-close indexes (catalog updates) Michael Paquier <michael@paquier.xyz>
Re: Avoid overhead open-close indexes (catalog updates) Ranier Vilela <ranier.vf@gmail.com>
Re: Avoid overhead open-close indexes (catalog updates) Michael Paquier <michael@paquier.xyz>
Re: Avoid overhead open-close indexes (catalog updates) Michael Paquier <michael@paquier.xyz>
Re: Avoid overhead open-close indexes (catalog updates) Ranier Vilela <ranier.vf@gmail.com>
Re: Avoid overhead open-close indexes (catalog updates) Michael Paquier <michael@paquier.xyz>
Re: Avoid overhead open-close indexes (catalog updates) Michael Paquier <michael@paquier.xyz>
Re: Avoid overhead open-close indexes (catalog updates) Ranier Vilela <ranier.vf@gmail.com>
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
В списке pgsql-hackers по дате отправления
От: Laurenz Albe
Дата:
От: Michael Paquier
Дата:
Сообщение: Re: Unit tests for SLRU
FAQ