Re: [HACKERS] REINDEX CONCURRENTLY 2.0

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] REINDEX CONCURRENTLY 2.0
Дата
Msg-id CA+TgmoY9wOS85dN9MNbzBuRzTZCFrswRDjydY1wh+HL9FCeFwA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] REINDEX CONCURRENTLY 2.0  (Andreas Karlsson <andreas@proxel.se>)
Ответы Re: [HACKERS] REINDEX CONCURRENTLY 2.0
Re: [HACKERS] REINDEX CONCURRENTLY 2.0
Список 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 по дате отправления:

Предыдущее
От: Pavan Deolasee
Дата:
Сообщение: Re: [HACKERS] Skip all-visible pages during second HeapScan of CIC
Следующее
От: Pavan Deolasee
Дата:
Сообщение: Re: [HACKERS] Skip all-visible pages during second HeapScan of CIC