Re: Vacuum is needed or not?

Поиск
Список
Период
Сортировка
От Guido Barosio
Тема Re: Vacuum is needed or not?
Дата
Msg-id f7f6b4c70601050930j453ff4f1oee20a509e4a9a300@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Vacuum is needed or not?  (Jaime Casanova <systemguards@gmail.com>)
Список pgsql-admin
 
Read all, in order to understand the following quote:
 
"

Since periodic VACUUM runs are needed anyway for the reasons described earlier, it's unlikely that any table would not be vacuumed for as long as a billion transactions. But to help administrators ensure this constraint is met, VACUUM stores transaction ID statistics in the system table pg_database. In particular, the datfrozenxid column of a database's pg_database row is updated at the completion of any database-wide VACUUM operation (i.e., VACUUM that does not name a specific table). The value stored in this field is the freeze cutoff XID that was used by that VACUUM command. All normal XIDs older than this cutoff XID are guaranteed to have been replaced by FrozenXID within that database. A convenient way to examine this information is to execute the query

SELECT datname, age(datfrozenxid) FROM pg_database;
"
 
Best wishes,
Guido

 
On 1/5/06, Jaime Casanova <systemguards@gmail.com> wrote:
On 1/5/06, Szabolcs BALLA <szballa@confinsystems.com> wrote:
>
>
VACUUM is needed at least every billion transactions...

execute it in a
> script periodically... if you are in doubt if you need
VACUUM then you need
> it urgently, execute it right now!!!

>
> yes, and i running every weekend a full analyze, but actually i think it's
> need again, but just for feel i couldn't stop the server.
> I need evidence. (oldspice rulez ;))
>
> Szabek

a plain VACUUM (without full) is enough in most cases... and you don't
need to stop the server for a plain VACUUM...

--
regards,
Jaime Casanova
(DBA: DataBase Aniquilator ;)

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
      subscribe-nomail command to majordomo@postgresql.org so that your
      message can get through to the mailing list cleanly



--
"Adopting the position that you are smarter than an automaticoptimization algorithm is generally a good way to achieve lessperformance, not more" - Tom Lane.

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

Предыдущее
От: Jaime Casanova
Дата:
Сообщение: Re: Vacuum is needed or not?
Следующее
От: "Jim C. Nasby"
Дата:
Сообщение: Re: preventing deadlocks