From: | Matthew Planchard <matthew(at)specprotected(dot)com> |
---|---|
To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
Cc: | pgsql-admin(at)lists(dot)postgresql(dot)org |
Subject: | Re: Index recreation details with REINDEX TABLE CONCURRENTLY |
Date: | 2023-05-11 17:03:40 |
Message-ID: | CAFw+HFSCH53-upkPVmSuthUv80a991g7GpgyepZh29VJevykMA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
That’s great, thank you very much!
On Thu, May 11, 2023 at 11:09 Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> wrote:
> On Wed, 2023-05-10 at 10:04 -0500, Matthew Planchard wrote:
> > We're working on setting up some regular jobs to reindex tables where we
> > wind up generating a lot of index bloat. We're planning on using REINDEX
> > ... CONCURRENTLY. We'd like to reindex all of the indexes on the tables.
> >
> > In some of our environments, these tables are very large and under high
> > load, and we want to minimize the resource consumption of index
> > recreation if possible.
> >
> > With that in mind, my question is: does REINDEX TABLE CONCURRENTLY
> > operate on the indexes of the table in parallel, or sequentially? If
> > in parallel, I imagine we would see less DB resource utilization by
> > updating one index at a time.
>
> If you use REINDEX TABLE CONCURRENTLY, the indexes will be built one
> after the other. Set "max_parallel_maintenance_workers" to 0 to keep
> the resource utilization low (at the price of a longer duration).
>
> Yours,
> Laurenz Albe
>
From | Date | Subject | |
---|---|---|---|
Next Message | kyle Hailey | 2023-05-11 19:05:36 | ATTACH PARTITION "hangs" |
Previous Message | Katherine Mcmillan | 2023-05-11 16:19:16 | Re: Index recreation details with REINDEX TABLE CONCURRENTLY |