Re: When/if to Reindex

Поиск
Список
Период
Сортировка
Искать
От
Steven Flatt
Тема
Re: When/if to Reindex
Дата
Msg-id
357fa7590708220955h441cd75ap4c0f0342a1c30a14@mail.gmail.com
Ответ на
Re: When/if to Reindex (Steven Flatt)
Список
Дерево обсуждения
When/if to Reindex "Steven Flatt" <steven.flatt@gmail.com>
Re: When/if to Reindex "Jim C. Nasby" <decibel@decibel.org>
Re: When/if to Reindex Vivek Khera <vivek@khera.org>
Re: When/if to Reindex "Steven Flatt" <steven.flatt@gmail.com>
Re: When/if to Reindex Bill Moran <wmoran@collaborativefusion.com>
Re: When/if to Reindex Tom Lane <tgl@sss.pgh.pa.us>
Re: When/if to Reindex "Steven Flatt" <steven.flatt@gmail.com>
Re: When/if to Reindex "Steven Flatt" <steven.flatt@gmail.com>
Re: When/if to Reindex Gregory Stark <stark@enterprisedb.com>
Re: When/if to Reindex "Steven Flatt" <steven.flatt@gmail.com>
Re: When/if to Reindex Tom Lane <tgl@sss.pgh.pa.us>
Re: When/if to Reindex Mark Kirkwood <markir@paradise.net.nz>
Re: When/if to Reindex "Steven Flatt" <steven.flatt@gmail.com>
Re: When/if to Reindex Tom Lane <tgl@sss.pgh.pa.us>
Re: When/if to Reindex "Steven Flatt" <steven.flatt@gmail.com>
Re: When/if to Reindex Tom Lane <tgl@sss.pgh.pa.us>
Re: When/if to Reindex Bruce Momjian <bruce@momjian.us>
Re: When/if to Reindex "Steven Flatt" <steven.flatt@gmail.com>
Re: When/if to Reindex Gregory Stark <stark@enterprisedb.com>
Re: When/if to Reindex Tom Lane <tgl@sss.pgh.pa.us>
Re: When/if to Reindex Gregory Stark <stark@enterprisedb.com>
Re: When/if to Reindex Decibel! <decibel@decibel.org>
Re: When/if to Reindex Bill Moran <wmoran@collaborativefusion.com>
It makes more sense for us to have ~1 hour's worth of reindexing afterwards during which read performance on that partition is "compromised".
 
So, based on the docs, I was expecting read performance to be compromised during a reindex, specifically reads would not be allowed to use the index:
 
"REINDEX locks out writes but not reads of the index's parent table. It also takes an exclusive lock on the specific index being processed, which will block reads that attempt to use that index."

However I'm seeing that all readers of that table are blocked until the reindex finishes, even reads that do not attempt to use the index.  Is this a problem with the docs or a bug?
 
I'm considering creating a new index with the same definition as the first (different name), so while that index is being created, read access to the table, and the original index, is not blocked.  When the new index is created, drop the original index and rename the new index to the original, and we've essentially accomplished the same thing.  In fact, why isn't reindex doing this sort of thing in the background anways?
 
Thanks,
Steve
 
В списке pgsql-performance по дате отправления
От: Steinar H. Gunderson
Дата:
От: Oleg Bartunov
Дата:
FAQ