Re: More Praise for 7.4RC2

Поиск
Список
Период
Сортировка
От Reece Hart
Тема Re: More Praise for 7.4RC2
Дата
Msg-id 1068826251.2620.55.camel@tallac
обсуждение исходный текст
Ответ на Re: More Praise for 7.4RC2  ("scott.marlowe" <scott.marlowe@ihs.com>)
Ответы Re: More Praise for 7.4RC2  (Greg Stark <gsstark@mit.edu>)
Список pgsql-general
On Thu, 2003-11-13 at 13:10, scott.marlowe wrote:
So, if your table is HIGHLY updated, you may need to run a plain vacuum 
very often, and that's where the autovacuum daemon comes in handy.  Just 
set it to run every 30 minutes or so, and let it go.  It should only 
vacuum the tables that have had lots of change, and leave the others 
alone.

On Thu, 2003-11-13 at 19:37, Greg Stark wrote:
However on a big heavily used database where the fsm parameters haven't been
raised from the defaults it's possible that it isn't. And on a table where
large batch updates or deletes have been run it's possible to require a vacuum
full after the batch job creates lots of dead tuples.
 Scott & Greg-

Thanks for this info. I'm sure this explains at least part of the problem. I can't remember the sequence of events from several months back, but I did once update ~20M rows of this 40M row this table, and I have also deleted certain sets of rows at various times. Suspecting that I had a swiss-cheese table, I reclustered on an index several times (which, I presume, is at least as good as vacuum (non-full) removing internal free space, with the benefit of optimized row ordering). Since I can't remember the order of operations, it's possible that I timed the slow query at nearly the worst state, and it's the kinda think I only wanted to endure once.

Thanks again,
Reece

-- 
Reece Hart, http://www.in-machina.com/~reece/, GPG:0x25EC91A0

В списке pgsql-general по дате отправления:

Предыдущее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: embedded postgresql + C++ IDE
Следующее
От: "Thomas LeBlanc"
Дата:
Сообщение: Loggin SQL Statements from JBOSS/JDBC