Re: Decent VACUUM (was: Buglist)

Manfred Koizar <mkoi-pg@aon.at> writes:
> better.  AFAICS Vivek's problem is that it is hard enough to hold a
> good part of the working set in the cache, and still his disks are
> saturated.  Now a VACUUM not only adds one more process to disk I/O
> contention, but also makes sure that the working set pages are *not*
> in memory which leads to higher I/O rates after the VACUUM.

We have had some people looking at improved buffer management
algorithms; LRU-2 or something smarter would help.  I dunno whether
we can dissuade the kernel from flushing its cache though.

> If we teach VACUUM to not read pages that don't contain any dead
> tuples, this could be a significant improvement.  I'm envisioning a
> data structure (reclaimable space map, RSM) similar to the FSM.
> Whenever a backend encounters a dead tuple it inserts a reference to
> its page into the RSM.

This assumes that backends will visit dead tuples with significant
probability.  I doubt that assumption is tenable; it's certainly not
if you assume that no backend is doing seqscans.  (And if they are,
then VACUUM is not the only I/O culprit...)

            regards, tom lane