From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Ed L(dot)" <pgsql(at)bluepolka(dot)net> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Interpreting vacuum verbosity |
Date: | 2004-05-07 17:25:14 |
Message-ID: | 14232.1083950714@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"Ed L." <pgsql(at)bluepolka(dot)net> writes:
> No, our autovac logs the number of changes (upd+del for vac, upd+ins+del for
> analyze) on each round of checks, and we can see it was routinely
> performing when expected. The number of updates/deletes just far exceeded
> the thresholds. Vac threshold was 2000, and at times there might be
> 300,000 outstanding changes in the 10-30 minutes between vacuums.
Well, in that case you probably want a lot less than "10-30 minutes"
between vacuums, at least for this particular table. I don't know how
one configures autovac for this, but I suppose it can be done ...
> max_fsm_relations = 1000 and max_fsm_pages = 10000.
Also you doubtless need max_fsm_pages a lot higher than that. A
conservative setting would make it as big as your whole database,
eg for a 10Gb disk footprint use 10Gb/8K (something upwards of
a million) FSM page slots.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Eduardo Pérez Ureta | 2004-05-07 17:25:54 | Storing a file hash as primary key |
Previous Message | Mark Harrison | 2004-05-07 16:43:16 | any experience with multithreaded pg apps? |