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 .
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 |