Alvaro Herrera escribió:
> Here's a first cut at this. Note I have omitted a setting equivalent to
> autovacuum_freeze_max_age, but I think we should have one too.
Some more comments on the patch:
* 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.
* The multixact_freeze_table_age value has been set to 5 million.
I feel this is a big enough number that shouldn't cause too much
vacuuming churn, while at the same time not leaving excessive storage
occupied by pg_multixact/members, which amplifies the space used by the
average number of member in each multi.
(A bit of math: each Xid uses 2 bits. Therefore for the default 200
million transactions of vacuum_freeze_table_age we use 50 million bytes,
or about 27 MB of space, plus some room for per-page LSNs. For each
Multi we use 4 bytes in offset plus 5 bytes per member; if we consider 2
members per multi in average, that totals 70 million bytes for the
default multixact_freeze_table_age, so 66 MB of space.)
* I have named the parameters by simply replacing "vacuum" with
"multixact". I could instead have added the "multixact" word in the
middle:
vacuum_multixact_freeze_min_age
but this doesn't seem an improvement.
* In the word "Multixact" in the docs I left the X as lowercase. I used
uppercase first but that looked pretty odd. In the middle of a
sentence, the M is also lowercase.
I reworded the paragraph in maintenance.sgml a bit. If there are
suggestions, please shout.
<para>
Similar to transaction IDs, Multixact IDs are implemented as a 32-bit
counter and corresponding storage which requires careful aging management,
storage cleanup, and wraparound handling. Multixacts are used to implement
row locking by multiple transactions: since there is limited space in the
tuple header to store lock information, that information is stored
separately
and only a reference to it is in the <structfield>xmax</> field in the
tuple
header.
</para>
<para>
As with transaction IDs,
<command>VACUUM</> is in charge of removing old values. Each
<command>VACUUM</> run sets
<structname>pg_class</>.<structfield>relminmxid</>
indicating the oldest possible value still stored in that table; every time
this value is older than <xref linkend="guc-multixact-freeze-table-age">, a
full-table scan is forced.
During any table scan (either partial or full-table), any multixact older
than <xref linkend="guc-multixact-freeze-min-age"> is replaced by something
else, which can be the zero value, a single transaction ID,
or a newer multixact. Eventually, as all tables in all databases are
scanned and their oldest multixact values are advanced, on-disk storage for
older multixacts can be removed.
</para>
</sect3>
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
