Re: Too many WAL(s) despite low transaction

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: Too many WAL(s) despite low transaction
Дата
Msg-id 20110401022209.GD4116@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: Too many WAL(s) despite low transaction  (Selva manickaraja <mavles78@gmail.com>)
Ответы Re: Too many WAL(s) despite low transaction
Список pgsql-admin
* Selva manickaraja (mavles78@gmail.com) wrote:
> 1. Set archive_timeout = 20m (Does the change require db restart to take
> effect?)

I *think* it can be changed with just a reload, but I'm not 100% sure.
Check your logs after doing the reload, it'll complain if it isn't able
to change that parameter on reload.

20m sounds reasonable, still would recommend compressing the WALs if
they're likely to be less than full (less than 16M of data in 20m).

> 2. Set  autovacuum=on and track_count=on (Does the change require db restart
> to take effect?)
>     Does that mean we are running autovacuum?

This is the default, so unless you changed the default, yes, it's
already running.

> 3. Run VACUUM FREEZE ANALYZE since bulk loading was done earlier. (Can this
> be done while the db is active and on production?)

Yes, you can freeze records while the DB is running (erm, I don't know
that you can run it w/o the DB running..).  I don't know that I'd jump
to running it right away though, unless you know that you need it...?

> All 3 steps is to lower the WAL files that are being shipped out.

Uhh, the only option that's going to affect that is the first one..

> Is this a workable action to achieve the result required?

You probably just need to change archive_timeout and reload the
database.  Well, you also need to go read the documentation, but that's
beside the point.

> Please assist.

Uhm, pretty sure I have been?

    Thanks,

        Stephen

Вложения

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

Предыдущее
От: Selva manickaraja
Дата:
Сообщение: Re: Too many WAL(s) despite low transaction
Следующее
От: Selva manickaraja
Дата:
Сообщение: Re: Too many WAL(s) despite low transaction