Re: [HACKERS] Buglist - Mailing list pgsql-general

On 22 Aug 2003 at 11:03, Jan Wieck wrote:

> Tom Lane wrote:
>
> > Jan Wieck <JanWieck@Yahoo.com> 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.

This kind of information does not really help autovacuum. If we are talking
about modifying backend stat collection algo., so that vacuum does minimum
work, is has translate to cheaper vacuum analyze so that autovacuum can fire it
at will any time. In the best case, another resident process like stat
collector can keep cleaning the deads.

This information must be in terms of pages and actually be maintained as per
page stat. Looking at number of tuples values does not give any idea to vacuum
how it is going to flush cache lines, either in postgresql or on OS. I doubt it
will help vacuum command in itself to be any lighter or more efficient.

If it is easy to do, I would favour maitaining two page maps as I mentioned in
another mail. One for pages in cache but not locked by any transaction and
another for pages which has some free space. If it is rare for a page to be
full, we can skip the later one. I think that could be good enough.




Bye
 Shridhar

--
Office Automation:    The use of computers to improve efficiency in the office    by
removing anyone you would want to talk with over coffee.