Re: [SQL] Deleting indexes before vacuum?
От | Tom Lane |
---|---|
Тема | Re: [SQL] Deleting indexes before vacuum? |
Дата | |
Msg-id | 20832.943240704@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | RE: [SQL] Deleting indexes before vacuum? ("Hiroshi Inoue" <Inoue@tpf.co.jp>) |
Ответы |
RE: [SQL] Deleting indexes before vacuum?
|
Список | pgsql-sql |
"Hiroshi Inoue" <Inoue@tpf.co.jp> writes: >> I have been toying with the notion of ripping out the existing VACUUM >> index handling code and putting in fresh code that would simply do an >> index drop and rebuild ;-). > Shouldn't vacuum preserve consistency even in case of abort ? That would be nice, certainly, but the existing code doesn't guarantee it either, and I don't see how we could guarantee it by any method. If you're moving tuples around then you are going to have some inconsistent intermediate states :-(. However, the big problem in that respect is an abort while vacuum is reshuffling the data in the table itself; changing our approach to index vacuuming isn't going to make any difference there. Once the table is finished and vacuum moves on to fixing the indexes, an abort would leave the index(es) corrupt but the table data should be OK. So the issue is how to recover the indexes after that happens. > Rebuiding indexes in vacuum has a big flaw that index may vanish in > case of abort and we may have to recreate index manually. The index won't "vanish" --- I see no reason to touch the system-table entries for it. The data in the index might be corrupt, but that can happen now. ISTM that a big advantage of the rebuild approach is that if something does go wrong during the index-fixing phase, you can try to recover just by doing another vacuum. That strikes me as less "manual" than dropping and rebuilding the indexes, which is the only available recovery path now. It might even work for an index on a system table... regards, tom lane
В списке pgsql-sql по дате отправления: