Re: Experimental patch for inter-page delay in VACUUM

The delay patch worked so well, I couldn't resist asking if a similar patch
could be added for COPY command (pg_dump). It's just an extension of the
same idea. On a large DB, backups can take very long while consuming a lot
of IO slowing down other select and write operations. We operate on a backup
window during low traffic period at night. It'll be nice to be able to run
pg_dump *anytime* and no longer need to worry about the backup window.
Backups will take longer to run, but like in the case of the VACUUM, it's a
win for many people to be able to let it run in the background through the
whole day. The delay should be optional and defaults to zero so those who
wish to backup immediately can still do it. The way I see it, routine
backups and vacuums should be ubiquitous once properly configured.

Regards,

Stephen

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote in message
news:15456(dot)1067796035(at)sss(dot)pgh(dot)pa(dot)us(dot)(dot)(dot)
> Jan Wieck <JanWieck(at)Yahoo(dot)com> writes:
> > I am currently looking at implementing ARC as a replacement strategy. I
> > don't have anything that works yet, so I can't really tell what the
> > result would be and it might turn out that we want both features.
>
> It's likely that we would. As someone (you?) already pointed out,
> VACUUM has bad side-effects both in terms of cache flushing and in
> terms of sheer I/O load. Those effects require different fixes AFAICS.
>
> One thing that bothers me here is that I don't see how adjusting our
> own buffer replacement strategy is going to do much of anything when
> we cannot control the kernel's buffer replacement strategy. To get any
> real traction we'd have to go back to the "take over most of RAM for
> shared buffers" approach, which we already know to have a bunch of
> severe disadvantages.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>