Re: truncating pg_multixact/members - Mailing list pgsql-hackers

From Robert Haas
Subject Re: truncating pg_multixact/members
Date
Msg-id CA+TgmoYdAKLMGpgtJ_8zPSHARvHcK+sbSBf7bZ1DTD5LwPj_Zg@mail.gmail.com
Whole thread Raw
In response to Re: truncating pg_multixact/members  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: truncating pg_multixact/members  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On Mon, Jan 20, 2014 at 1:39 PM, Alvaro Herrera
<alvherre@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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Add %z support to elog/ereport?
Next
From: Fujii Masao
Date:
Subject: Bug? could not remove shared memory segment