Jan Wieck <[EMAIL PROTECTED]> writes:Shridhar Daithankar wrote:Umm.. What does FSM does then? I was under impression that FSM stores page pointers and vacuum work on FSM information only. In that case, it wouldn't have to waste time to find out which pages to clean.
It's the other way around! VACUUM scan's the tables to find and reclaim free space and remembers that free space in the FSM.
Right. One big question mark in my mind about these "partial vacuum" proposals is whether they'd still allow adequate FSM information to be maintained. If VACUUM isn't looking at most of the pages, there's no very good way to acquire info about where there's free space.
That's why I think it needs one more pg_stat column to count the number of vacuumed tuples. If one does
tuples_updated + tuples_deleted - tuples_vacuumed
he'll get approximately the number of tuples a regular vacuum might be able to reclaim. If that number is really small, no need for autovacuum to cause any big trouble by scanning the relation.
Another way to give autovacuum some hints would be to return some number as commandtuples from vacuum. like the number of tuples actually vacuumed. That together with the new number of reltuples in pg_class will tell autovacuum how frequent a relation really needs scanning.
Jan
-- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== [EMAIL PROTECTED] #
---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
