On Tue, Feb 11, 2014 at 5:16 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > Robert Haas escribió: >> On Mon, Jan 20, 2014 at 1:39 PM, Alvaro Herrera >> <alvhe...@2ndquadrant.com> wrote: >> > * I haven't introduced settings to tweak this per table for >> > autovacuum. I don't think those are needed. It's not hard to do, >> > however; if people opine against this, I will implement that. >> >> I can't think of any reason to believe that it will be less important >> to tune these values on a per-table basis than it is to be able to do >> the same with the autovacuum parameters. Indeed, all the discussion >> on this thread suggests precisely that we have no real idea how to set >> these values yet, so more configurability is good. Even if you reject >> that argument, I think it's a bad idea to start making xmax vacuuming >> and xmin vacuuming less than parallel; such decisions confuse users. > > Yeah, I can relate to this argument. I have added per-table > configurability to this, and also added the an equivalent of > autovacuum_freeze_max_age to force a for-wraparound full scan of a table > based on multixacts. > > I haven't really tested this beyond ensuring that it compiles, and I > haven't changed the default values, but here it is in case someone wants > to have a look and comment --- particularly on the doc additions.
Using Multixact capitalized just so seems odd to me. Probably should be lower case (multiple places). This part needs some copy-editing: + <para> + Vacuum also allows removal of old files from the + <filename>pg_multixact/members</> and <filename>pg_multixact/offsets</> + subdirectories, which is why the default is a relatively low + 50 million transactions. Vacuuming multixacts also allows...? And: 50 million multixacts, not transactions. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers