Re: Per-table freeze limit proposal

Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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