Re: Bloated tables and why is vacuum full the only option
От | Claudio Freire |
---|---|
Тема | Re: Bloated tables and why is vacuum full the only option |
Дата | |
Msg-id | CAGTBQpadv938fU7RkQHnMzRkmBJykm-BOE=Eiykv6RTkxQzaow@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Bloated tables and why is vacuum full the only option (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-performance |
On Sun, Feb 9, 2014 at 4:40 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Claudio Freire <klaussfreire@gmail.com> writes: >>>> I also do routine reindexing to stop index bloat on its tracks, yet >>>> freshly-reindexed indexes get considerably reduced in size with vacuum >>>> full. > > AFAIK there's no reason for vacuum full to produce a different result > from reindex. Did you mean to say that the indexes get smaller than > what they had been after some normal operation? If so it's worth noting > this comment from the btree index building code (nbtsort.c): Smaller than after reindex. It was a surprise to me too. > Also, there are certain usage patterns that can result in btree indexes > having densities much lower than the conventional-wisdom 70%. The main > one I've seen in practice is "decimation", where you delete say 99 out > of every 100 entries in index order. This leaves just a few live entries > in each leaf page --- but our btree code doesn't reclaim an index page > for recycling until it's totally empty. So you can end up with a very > low load factor after doing something like that, and a reindex is the > only good way to fix it. That's exactly the kind of pattern the "archival" step results in, that's why I do routine reindexing.
В списке pgsql-performance по дате отправления: