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

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:

Reply via email to