"ITAGAKI Takahiro" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
