Re: VACUUMs take twice as long across all nodes

Поиск
Список
Период
Сортировка
От Gavin Hamill
Тема Re: VACUUMs take twice as long across all nodes
Дата
Msg-id 20061026160609.5e94e581.gdh@laterooms.com
обсуждение исходный текст
Ответ на Re: VACUUMs take twice as long across all nodes  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: VACUUMs take twice as long across all nodes  ("Jim C. Nasby" <jim@nasby.net>)
Список pgsql-performance
On Thu, 26 Oct 2006 10:47:21 -0400
Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Gavin Hamill <gdh@laterooms.com> writes:
> > Nodes 2 and 3 take only the tables necessary to run our search (10
> > out of the full 130) and are much lighter (only 7GB on disk cf.
> > 30GB for the full master) , yet the nightly VACUUM FULL has jumped
> > from 2 hours to 4 in the space of one day!
>
> I guess the most useful question to ask is "why are you doing VACUUM
> FULL?" Plain VACUUM should be considerably faster, and for the level
> of row turnover shown by your log, there doesn't seem to be a reason
> to use FULL.

I do FULL on the 'light' clients simply because 'I can'. The example
posted was a poor choice - the other tables have a larger churn.

Anyway, once it starts, the load balancer takes it out of rotation so
no love is lost.

The same behaviour is shown on the 'heavy' clients (master + 2 slaves)
which take all tables - although I cannot afford to VACUUM FULL on
there, the usual VACUUM ANALYZE has begun to take vastly more time
since yesterday than in the many previous months we've been using pg.

Cheers,
Gavin.

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

Предыдущее
От: "Merlin Moncure"
Дата:
Сообщение: Re: commit so slow program looks frozen
Следующее
От: "Matthew Peters"
Дата:
Сообщение: Stored procedure slower than sql?