Manfred Koizar <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
