Re: REINDEX CONCURRENTLY 2.0
Michael Paquier <michael.paquier@gmail.com>
From: Michael Paquier <michael.paquier@gmail.com>
To: Andreas Karlsson <andreas@proxel.se>
Cc: Andres Freund <andres@2ndquadrant.com>,
Robert Haas <robertmhaas@gmail.com>, Peter Eisentraut <peter_e@gmx.net>, Jim Nasby <jim@nasby.net>, PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Date: 2017-02-14T03:56:57Z
Lists: pgsql-hackers
On Tue, Feb 14, 2017 at 11:32 AM, Andreas Karlsson <andreas@proxel.se> wrote: > On 02/13/2017 06:31 AM, Michael Paquier wrote: >> Er, something like that as well, no? >> DETAIL: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s. > > REINDEX (VERBOSE) currently prints one such line per index, which does not > really work for REINDEX (VERBOSE) CONCURRENTLY since it handles all indexes > on a relation at the same time. It is not immediately obvious how this > should work. Maybe one such detail line per table? Hard to recall this thing in details with the time and the fact that a relation is reindexed by processing all the indexes once at each step. Hm... What if ReindexRelationConcurrently() actually is refactored in such a way that it processes all the steps for each index individually? This way you can monitor the time it takes to build completely each index, including its . This operation would consume more transactions but in the event of a failure the amount of things to clean up is really reduced particularly for relations with many indexes. This would as well reduce VERBOSE to print one line per index rebuilt. -- Michael
Commits
-
Prevent reindex of invalid indexes on TOAST tables
- 8bca5f93547c 12.3 landed
- 61d7c7bce368 13.0 landed
-
Rework handling of invalid indexes with REINDEX CONCURRENTLY
- a6dcf9df4d91 12.0 landed
-
Split builtins.h to a new header ruleutils.h
- 7b1c2a0f2066 9.5.0 cited