Re: Per-table freeze limit proposal - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Per-table freeze limit proposal
Date
Msg-id 9603.1126755052@sss.pgh.pa.us
Whole thread Raw
In response to Per-table freeze limit proposal  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: Per-table freeze limit proposal
List pgsql-hackers
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> In fact this seems pretty easy to do.  Add a field to pg_class, tell
> VACUUM to update it using the determined freezeLimit, and that's it.

I think that it'd be worth fixing things so that the recorded value
is not the freeze cutoff value (as now), but the actual lowest
not-frozen XID present anywhere in the table.  The present code does not
do that because it's painful to track across multiple tables, but on a
per-table basis it seems easy.  In particular this rule allows you to
set a sane value for the pg_class field when the table is created (ie,
current transaction's XMIN, rather than a billion less).

> (Note that if we ever implement partial vacuum, it won't be able to
> update the freeze point.  But that was true before anyway.)

Sure.

> We also need to teach autovacuum to update pg_database.datfreezexid,
> using the minimum from pg_class.

No, no, no.  autovacuum is not a required part of the system and it's
not going to become so any time soon.  Updating the pg_database entry
will have to be the responsibility of VACUUM itself.  It's not that
terrible: you don't have to scan pg_class unless you see that the
pg_class.relfreezexid value you are replacing is equal to
pg_database.datfreezexid, and with the exact computation suggested
above, that won't be a common occurrence.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: inverse OR distributive law?
Next
From: "Jonah H. Harris"
Date:
Subject: Re: About method of PostgreSQL's Optimizer