Re: REINDEX CONCURRENTLY 2.0
От | Jim Nasby |
---|---|
Тема | Re: REINDEX CONCURRENTLY 2.0 |
Дата | |
Msg-id | 52CF45E8.6090208@nasby.net обсуждение исходный текст |
Ответ на | REINDEX CONCURRENTLY 2.0 (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: REINDEX CONCURRENTLY 2.0
|
Список | pgsql-hackers |
Sorry for the lateness of this... On 11/14/13, 8:40 PM, Michael Paquier wrote: > + /* > + * Phase 4 of REINDEX CONCURRENTLY > + * > + * Now that the concurrent indexes have been validated could be used, > + * we need to swap each concurrent index with its corresponding old index. > + * Note that the concurrent index used for swaping is not marked as valid > + * because we need to keep the former index and the concurrent index with > + * a different valid status to avoid an implosion in the number of indexes > + * a parent relation could have if this operation fails multiple times in > + * a row due to a reason or another. Note that we already know thanks to > + * validation step that > + */ > + Was there supposed to be more to that comment? In the loop right below it... + /* Swap the indexes and mark the indexes that have the old data as invalid */ + forboth(lc, indexIds, lc2, concurrentIndexIds) ... + CacheInvalidateRelcacheByRelid(relOid); Do we actually need to invalidate the cache on each case? Is it because we're grabbing a new transaction each time through? -- Jim C. Nasby, Data Architect jim@nasby.net 512.569.9461 (cell) http://jim.nasby.net
В списке pgsql-hackers по дате отправления: