autovacuum question

Поиск
Список
Период
Сортировка
От Marc Mamin
Тема autovacuum question
Дата
Msg-id C4DAC901169B624F933534A26ED7DF311D5398@JENMAIL01.ad.intershop.net
обсуждение исходный текст
Ответы Re: autovacuum question  (Alvaro Herrera <alvherre@commandprompt.com>)
Список pgsql-admin
autovacuum question

Hello,

I'not using autovacuum as the largest part of my tables are filled with
COPY FROM, not modified afterward and dropped when obsolete.

Other tables are regularily vacuumed  from an application driven job
that knows which tables were modified recently.
(It also vacuums the pg_catalog tables).


I've choosen this scenario about 2 years ago, as autovacuum didn't seem
to be very mature.

I manage a couple of DBs, currently up to 800GB, with data similar to
wharehouses, with mainly bulk operations, so that the transaction IDs
are growing slowly. A single DB can contain up to 30'000 tables and
45'000 indexes


I want to simplify this process as I'm migrating from 8.2 to 8.3.


I could use pg_autovacuum to track all tables that do not need being
vacuumed, but this would not simplify much as I have a lot of tables
created/dropped dynamically.


There are 2 features that would be helpfull in my case:

- define vacuum properties on table groups rather than on given tables:

    For example, I don't want to vacuum daily tables which can be
identified with a regexp:
    tablename ~ '\.*d_[0-9]{8}'

- automatically remove the pg_autovacuum entry when a table is dropped
(well it's not such complicated...)


And  2 questions:

Can I disable track_counts when I'm not using autovacuum, or is it used
for other purposes ?

Free Space Map: is it affected by dropped tables ? Or more generally,
must I care with it in a special way in my situation ?

many thanks,

Marc Mamin





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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Warm standby recovery failure
Следующее
От: Cliff Pratt
Дата:
Сообщение: Re: [GENERAL] Encoding problem using pg_dumpall