Re: When/if to Reindex
От | Tom Lane |
---|---|
Тема | Re: When/if to Reindex |
Дата | |
Msg-id | 1759.1187972125@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: When/if to Reindex ("Steven Flatt" <steven.flatt@gmail.com>) |
Ответы |
Re: When/if to Reindex
|
Список | pgsql-performance |
"Steven Flatt" <steven.flatt@gmail.com> writes: >> The fly in the ointment is that after collecting the pg_index definition >> of the index, plancat.c also wants to know how big it is --- it calls >> RelationGetNumberOfBlocks. > Why do we even need to consider calling RelationGetNumberOfBlocks or looking > at the pg_class.relpages entry? My understanding of the expected behaviour > is that while a reindex is happening, all queries run against the parent > table are planned as though the index isn't there (i.e. it's unusable). Where in the world did you get that idea? If we had a REINDEX CONCURRENTLY it might work that way. A normal REINDEX cannot "mark" anything because it runs within a single transaction; there is no way that it can emit any catalog changes that will be visible before it's over. regards, tom lane
В списке pgsql-performance по дате отправления: