Re: VACUUM delay (was Re: What's planned for 7.5?)

The vacuum delay patch is not the ideal solution but it worked like a charm
on my servers. I really need the vacuum delay patch or a better solution in
7.5. I'm getting millions of requests a month and running VACUUM without the
patch makes PostgreSQL useless for many consecutive hours. Not quite the
24/7 system I was hopping for. :-(

Unfortunately, it's rather difficult to patch so many machines as my entire
system runs on Redhat RPMs. I'm really hopping to see a solution to this
VACUUM problem in 7.5. I've been waiting for this fix for over 3 years and
now it's almost there.

Will this problem get addressed in the not so official TODO list?

Thanks and keep up the good work!

Stephen





"Jan Wieck" <JanWieck@Yahoo.com> wrote in message
news:400544E3.8030709@Yahoo.com...
> Tom Lane wrote:
> > Christopher Browne <cbbrowne@libertyrms.info> writes:
> >> "Stephen" <jleelim@xxxxxxx.com> writes:
> >>> Any chance we'll see the VACUUM delay patch (throttle) get into 7.5?
> >
> >> The hope, in 7.5, is to have ARC, which is the "super-duper-duper"
> >> version, working.
> >
> > Actually, I'm not sure that ARC should be considered to supersede the
> > usefulness of a per-page delay in VACUUM.  ARC should prevent VACUUM
> > from trashing the contents of Postgres' shared buffer arena, but it
> > won't do much of anything to prevent VACUUM from trashing the kernel
> > buffer contents.  And it definitely won't do anything to help if the
> > real problem is that you're short of disk bandwidth and VACUUM's extra
> > I/O demand pushes your total load over the knee of the response-time
> > curve.  What you need then is a throttle.
> >
> > The original patch I posted was incomplete for a number of reasons,
> > but I think it may still be worth working on.  Jan, any comments?
>
> I agree that there is considerable value in IO distribution. As such I
> already have the basics of the Background Writer in there.
>
> I left out the vacuum delay since I thought it was good enough to proove

> that there is low hanging fruit, but that it was far from what I'd call
> a solution. Ideally Vacuum would coordinate it's IO not only against
> some GUC variables, but also against the BGWriter+BufStrategy combo.
>
>
> Jan
>
> --
> #======================================================================#
> # It's easier to get forgiveness for being wrong than for being right. #
> # Let's break this rule - forgive me.                                  #
> #================================================== JanWieck@Yahoo.com #
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
>                http://archives.postgresql.org
>