Re: Decent VACUUM (was: Buglist)

Manfred Koizar <mkoi-pg(at)aon(dot)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