Re: Slow sequential scans on one DB but not another; fragmentation?
В списке pgsql-general по дате отправления:
| От | Stephen Harris |
|---|---|
| Тема | Re: Slow sequential scans on one DB but not another; fragmentation? |
| Дата | |
| Msg-id | 20070330221600.GA7506@pugwash.spuddy.org обсуждение |
| Ответ на | Re: Slow sequential scans on one DB but not another; fragmentation? (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-general |
On Wed, Mar 28, 2007 at 11:36:27AM -0400, Tom Lane wrote: > Stephen Harris <lists@spuddy.org> writes: > > INFO: "sweep_users": found 835831 removable, 972662 nonremovable row versions in 2890304 pages > Oy, that's one bloated table ... only one live row in every three or so pages. > > Probably a CLUSTER is the most effective way of cleaning it up. Once OK, we were doing a code release today and so had a change window open. We ran a cluster command on this table. It took 15 minutes to complete, and the number of pages went down to 27,000 - ie by a factor of 100. "select count(*)" took 4 seconds instead of 220, giving us a 55 times speed increase. We'll keep our eye on this but since it was relatively quick we might schedule a weekly cluster "just in case". Thanks! -- rgds Stephen
В списке pgsql-general по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера