Re: Index recreation details with REINDEX TABLE CONCURRENTLY

From: Ron <ronljohnsonjr(at)gmail(dot)com>
To: pgsql-admin(at)lists(dot)postgresql(dot)org
Subject: Re: Index recreation details with REINDEX TABLE CONCURRENTLY
Date: 2023-05-10 20:36:02
Message-ID: 5ec087d5-e07c-e704-96cd-a3f8fb9f91d7@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

On 5/10/23 10:04, Matthew Planchard wrote:
> Hello,
>
> 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.

https://www.postgresql.org/docs/11/sql-createindex.html

The CREATE INDEX page certainly mentions parallel index builds.  It would
definitely be very good to know whether REINDEX TABLE CONCURRENTLY can have
multiple "threads" leveraging table data already in cache so as not to have
to reread the whole table each time.

That (concurrent CREATE INDEX statements) really sped things up Back In The
Day).

--
Born in Arizona, moved to Babylonia.

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message James Fraley 2023-05-10 21:01:18 Re: Index recreation details with REINDEX TABLE CONCURRENTLY
Previous Message Dhirendra Singh 2023-05-10 15:32:54 Re: Question about pg_wal.tar.gz generated by pg_basebackup