On Wed, Oct 25, 2023 at 11:33:11AM +0200, Andreas Kretschmer wrote: > Am 25.10.23 um 11:24 schrieb Matthias Apitz: >> We have a client who run REINDEX in certain tables of the database of >> our application (on Linux with PostgreSQL 13.x): >> >> REINDEX TABLE CONCURRENTLY d83last; >> REINDEX TABLE CONCURRENTLY d86plz; >> REINDEX TABLE CONCURRENTLY ig_memtable; >> REINDEX TABLE CONCURRENTLY ig_dictionary; >> REINDEX TABLE CONCURRENTLY ig_dictionary; >> REINDEX TABLE CONCURRENTLY d50zweig ; >> REINDEX TABLE CONCURRENTLY d50zweig ; >> >> We as the software vendor and support, do not use or recommend this >> procedure, because we have own SQL files for creating or deleting >> indices in the around 400 tables. >> >> The client is now concerned about the issue that the number of >> rows in some of the above tables has increased. Is this possible? > > In principle, there is nothing wrong with doing this in a maintenance > window, for example. If you have a maintenance window where your production server is not going to be active, you may want to just do a more aggressive REINDEX without CONCURRENTLY as that's going to be cheaper and faster. CONCURRENTLY is useful even in non-maintenance cases as it allows concurrent reads and writes to happen on the index while running the operation. CONCURRENTLY is much slower of course, as it needs to wait two times for older snapshots held by concurrent sessions when the index build is finished and when the index built gets validated. -- Michael
Attachment:
signature.asc
Description: PGP signature
