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

Поиск
Список
Период
Сортировка
От Ranier Vilela
Тема Re: Avoid overhead open-close indexes (catalog updates)
Дата
Msg-id CAEudQArpawTjkJUQoFwbQmVQtQi_xg1qBOW9NNb-FRrujZX5_w@mail.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>)
Список pgsql-hackers
Em qui., 10 de nov. de 2022 às 05:16, Michael Paquier <michael@paquier.xyz> escreveu:
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. 
That's the idea.
 
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.
For CopyStatistics() have performance checks.
 

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. 
Have a list_length call, for a number of vals.
For 2 or more vals, it is already worth it, since CatalogOpenIndexes/CatalogCloseIndexes will be called for each val.

 
update_attstats() should lead to a measurable difference
with a relation that has a bunch of attributes with few tuples.
Same here.
For 2 or more attributes, it is already worth it, since CatalogOpenIndexes/CatalogCloseIndexes will be called for each.

DefineTSConfiguration() is less of an issue, still fine to change.
Ok.

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.
One filter, only.

For all these functions, the only case that would possibly have no effect would be in the case of changing a single tuple, in which case there would be only one call CatalogOpenIndexes/CatalogCloseIndexes for both paths.


I still need to check properly the code paths changed here, of
course..
At least, the patch still applies properly.

regards,
Ranier Vilela

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: New docs chapter on Transaction Management and related changes
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: ExecRTCheckPerms() and many prunable partitions