Re: REINDEXdb performance degrading gradually PG13.4

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Praneel Devisetty <devisettypraneel(at)gmail(dot)com>
Cc: "pgsql-performa(dot)" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: REINDEXdb performance degrading gradually PG13.4
Date: 2022-06-01 17:41:07
Message-ID: CAMkU=1wR9Er2me8u=TL0vGNpMbig90bGryzzEXCpZs2y-apW3Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Tue, May 31, 2022 at 11:14 AM Praneel Devisetty <
devisettypraneel(at)gmail(dot)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

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Jeff Janes 2022-06-02 03:33:33 Re: rows selectivity overestimate for @> operator for arrays
Previous Message Praneel Devisetty 2022-06-01 07:06:41 Re: REINDEXdb performance degrading gradually PG13.4