Re: [HACKERS] REINDEX CONCURRENTLY 2.0 - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] REINDEX CONCURRENTLY 2.0
Date
Msg-id CA+TgmoY9wOS85dN9MNbzBuRzTZCFrswRDjydY1wh+HL9FCeFwA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] REINDEX CONCURRENTLY 2.0  (Andreas Karlsson <andreas@proxel.se>)
Responses Re: [HACKERS] REINDEX CONCURRENTLY 2.0  (Andres Freund <andres@anarazel.de>)
Re: [HACKERS] REINDEX CONCURRENTLY 2.0  (Andreas Karlsson <andreas@proxel.se>)
List 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



pgsql-hackers by date:

Previous
From: Pavan Deolasee
Date:
Subject: Re: [HACKERS] Skip all-visible pages during second HeapScan of CIC
Next
From: Pavan Deolasee
Date:
Subject: Re: [HACKERS] Skip all-visible pages during second HeapScan of CIC