"ITAGAKI Takahiro" <itagaki.takahiro@oss.ntt.co.jp> writes:
> I don't think we can supply such a historical database functionality here,
> because we can guarantee it just only for INSERTed tuples even if we pay
> attention. We've already enabled autovacuum as default, so that we cannot
> predict when the next vacuum starts and recently UPDATEd and DELETEd tuples
> are removed at random times. Furthermore, HOT will also accelerate removing
> expired tuples. Instead, we'd better to use WAL or something like audit
> logs for keeping history information.
Well comparing the data to WAL is precisely the kind of debugging that I think
Tom is concerned with.
The hoped for gain here is that vacuum finds fewer pages with tuples that
exceed vacuum_freeze_min_age? That seems useful though vacuum is still going
to have to read every page and I suspect most of the writes pertain to dead
tuples, not freezing tuples.
This strikes me as something that will be more useful once we have the DSM
especially if it ends up including a frozen map. Once we have the DSM vacuum
will no longer be visiting every page, so it will be much easier for pages to
get quite old and only be caught by a vacuum freeze. The less i/o that vacuum
freeze has to do the better. If we get a freeze map then agressive freezing
would help keep pages out of that map so they never need to be vacuumed just
to freeze the tuples in them.
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com
