Re: REINDEX CONCURRENTLY 2.0
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Andreas Karlsson <andreas@proxel.se>
Cc: Andres Freund <andres@anarazel.de>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>,
Jim Nasby <Jim.Nasby@bluetreble.com>, Michael Paquier <michael.paquier@gmail.com>
Date: 2017-03-08T02:48:23Z
Lists: pgsql-hackers
On Sun, Mar 5, 2017 at 7:13 PM, Andreas Karlsson <andreas@proxel.se> wrote: > And I would argue that his feature is useful for quite many, based on my > experience running a semi-large database. Index bloat happens and without > REINDEX CONCURRENTLY it can be really annoying to solve, especially for > primary keys. Certainly more people have problems with index bloat than the > number of people who store index oids in their database. Yeah, but that's not the only wart, I think. For example, I believe (haven't looked at this patch series in a while) that the patch takes a lock and later escalates the lock level. If so, that could lead to doing a lot of work to build the index and then getting killed by the deadlock detector. Also, if by any chance you think (or use any software that thinks) that OIDs for system objects are a stable identifier, this will be the first case where that ceases to be true. If the system is shut down or crashes or the session is killed, you'll be left with stray objects with names that you've never typed into the system. I'm sure you're going to say "don't worry, none of that is any big deal" and maybe you're right. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
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