| From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
|---|---|
| To: | Matthew Planchard <matthew(at)specprotected(dot)com>, pgsql-admin(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Index recreation details with REINDEX TABLE CONCURRENTLY |
| Date: | 2023-05-11 16:09:15 |
| Message-ID: | d7a69c286d6f721b55d14f79c9f0a37eed3c4845.camel@cybertec.at |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
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 | Katherine Mcmillan | 2023-05-11 16:19:16 | Re: Index recreation details with REINDEX TABLE CONCURRENTLY |
| Previous Message | Erik Wienhold | 2023-05-11 15:54:42 | Re: pg_stat_activity query_id |