Re: REINDEXdb performance degrading gradually PG13.4

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: REINDEXdb performance degrading gradually PG13.4
Дата
Msg-id CAMkU=1wR9Er2me8u=TL0vGNpMbig90bGryzzEXCpZs2y-apW3Q@mail.gmail.com
обсуждение исходный текст
Ответ на REINDEXdb performance degrading gradually PG13.4  (Praneel Devisetty <devisettypraneel@gmail.com>)
Список pgsql-performance
Дерево обсуждения


On Tue, May 31, 2022 at 11:14 AM Praneel Devisetty <devisettypraneel@gmail.com> wrote:

Hi,

We are trying to reindex 600k tables in a single database  of size 2.7TB
using reindexdb utility in a shell script
reindexdb -v -d $dbname -h $hostname -U tkcsowner --concurrently -j $parallel -S $schema


What is the value of $parallel?  Are all the tables in the same schema?
 
Initially it was processing 1000 tables per minute. Performance is gradually dropping and now after 24 hr it was processing 90 tables per minute.

I can't even get remotely close to 1000 per minute with those options, even with only 100000 single-index tables with all of them being empty.  Are you sure that isn't 1000 per hour?

Using --concurrently really hits the stats system hard (I'm not sure why).   Could you just omit that?  If it is running at 1000 per minute or even per hour, does it really matter if the table is locked for as long as it takes to reindex?

Cheers,

Jeff

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

Предыдущее
От: Praneel Devisetty
Дата:
Сообщение: Re: REINDEXdb performance degrading gradually PG13.4
Следующее
От: Jeff Janes
Дата:
Сообщение: Re: rows selectivity overestimate for @> operator for arrays