Re: REINDEXdb performance degrading gradually PG13.4

From: Praneel Devisetty <devisettypraneel(at)gmail(dot)com>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: REINDEXdb performance degrading gradually PG13.4
Date: 2022-06-01 07:06:41
Message-ID: CAHnVB4B+NEFQkncBa9p1ERES_6STKghYjAPCLonqLHy2s6=JTw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Tue, May 31, 2022 at 9:12 PM David G. Johnston <
david(dot)g(dot)johnston(at)gmail(dot)com> wrote:

> On Tuesday, May 31, 2022, Praneel Devisetty <devisettypraneel(at)gmail(dot)com>
> wrote:
>
>>
>> Initially it was processing 1000 tables per minute. Performance is
>>> gradually dropping and now after 24 hr it was processing 90 tables per
>>> minute.
>>>
>>
> That seems like a fairly problematic metric given the general vast
> disparities in size tables have.
>
> Building indexes is so IO heavy that the non-IO bottlenecks that exists
> likely have minimal impact on the overall times this rebuild everything
> will take. That said, I’ve never done anything at this scale before. I
> wouldn’t be too surprised if per-session cache effects are coming into play
> given the number of objects involved and the assumption that each session
> used for parallelism is persistent. I’m not sure how the parallelism works
> for managing the work queue though as it isn’t documented and I haven’t
> inspected the source code.
>

could you please share more about per-session cache effects /Point me to
link with more info .

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Jeff Janes 2022-06-01 17:41:07 Re: REINDEXdb performance degrading gradually PG13.4
Previous Message Michael Paquier 2022-06-01 04:37:37 Re: REINDEXdb performance degrading gradually PG13.4