Re: [HACKERS] autovacuum can't keep up, bloat just continues to rise
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] autovacuum can't keep up, bloat just continues to rise |
Дата | |
Msg-id | 13534.1500519429@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] autovacuum can't keep up, bloat just continues to rise (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: [HACKERS] autovacuum can't keep up, bloat just continues to rise
Re: [HACKERS] autovacuum can't keep up, bloat just continues to rise |
Список | pgsql-hackers |
Peter Geoghegan <pg@bowt.ie> writes: > My argument for the importance of index bloat to the more general > bloat problem is simple: any bloat that accumulates, that cannot be > cleaned up, will probably accumulate until it impacts performance > quite noticeably. But that just begs the question: *does* it accumulate indefinitely, or does it eventually reach a more-or-less steady state? The traditional wisdom about btrees, for instance, is that no matter how full you pack them to start with, the steady state is going to involve something like 1/3rd free space. You can call that bloat if you want, but it's not likely that you'll be able to reduce the number significantly without paying exorbitant costs. I'm not claiming that we don't have any problems, but I do think it's important to draw a distinction between bloat and normal operating overhead. regards, tom lane
В списке pgsql-hackers по дате отправления: