On Mon, Jun 8, 2009 at 10:40 AM, Alvaro Herrera<alvhe...@commandprompt.com> wrote: > Tom Lane escribió: >> Alvaro Herrera <alvhe...@commandprompt.com> writes: >> > Robert Haas escribió: >> >> Maybe we should just have a GUC to enable/disable >> >> partial vacuums. >> >> > IIRC you can set vacuum_freeze_table_age to 0. >> >> That has the same effects as issuing VACUUM FREEZE, no? > > As far as I can make from the docs, I think it only forces a full table > scan, but the freeze age remains the same.
Yeah, that looks like what I was looking for, thanks. I looked for it in the docs under the vacuum-related sections, but couldn't find it, and I didn't know the name of it so I couldn't find it that way either. I wonder if we should consider moving all of the vacuum and autovacuum parameters into one section. http://developer.postgresql.org/pgdocs/postgres/runtime-config-client.html#GUC-VACUUM-FREEZE-TABLE-AGE In the worst case scenario where the new partial-table-vacuums are causing headaches for someone, they should hopefully be able to use this parameter to basically turn them off without too many nasty side effects. (Another nice thing about this parameter is that if you have a really big table that is append-mostly, you can potentially tune this parameter downward to spread out the freezing activity. With the default settings, you might cruise along merrily until you hit 150M transactions and then generate an I/O storm as you freeze a pretty big chunk of the table all at once. With a lower setting, non-partial vacuums will be more frequent, but each one will generate a smaller amount of write traffic.) ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers