Re: pg_dump & performance degradation

I do not think it is a good idea to add some sleep-ability to pg_dump
unless we can get a general agreement that this is a valuable feature.

> At 13:36 28/07/00 -0400, Tom Lane wrote:
> >Philip Warner <pjw(at)rhyme(dot)com(dot)au> writes:
> >> Well...pg_dump sits in a loop reading COPY output; my hope was to see how
> >> long the copy took, and then wait an appropriate amount of time. The dummy
> >> select works nicely as a sleep call, but I can't really tell how long to
> >> sleep without a sub-second timer, or something that tells me the time
> >> between two calls.
> >
> >Seems like just delaying for a user-specifiable number of microseconds
> >between blocks or lines of COPY output would get the job done.
>
> You're probably right; and if I can't trust setitimer, sigaction and pause,
> then I guess I have no choice.
>
>
> > I'm not
> >clear what the reason is for needing to measure anything --- the user is
> >going to be tweaking the parameter anyway to arrive at what he feels is
> >an acceptable overall system load from the backup operation, so how are
> >you making his life easier by varying the delay?
> ...
> >We do have an existing dependency on gettimeofday() in postgres.c's
> >ShowUsage(), so if you really feel a compulsion to measure then that's
> >what to use. I don't see what it's buying you though.
>
> The plan was for the user to specify a single number that was the ratio of
> time spent sleeping to the time spent 'working' (ie. reading COPY lines).
>
> In the ordinary case this value would be 0 (no sleep), and for a very low
> load model it might be as high as 10 - for every 100ms spent working it
> spends 1000ms sleeping.
>
> This was intended to handle the arbitrary speed variations that occur when
> reading, eg, large toasted rows and reading lots of small normal rows. A
> simple 'wait 200ms' model would be fine for the former, but way too long
> for the latter.
>
> >(AFAIR no one's ever asked for this before, so...)
>
> like most of these things (at least for me), it is personally relevant: I
> also experience severe peformance degradation during backups.
>
> I'll look at gettimeofday...
>
>
> ----------------------------------------------------------------
> Philip Warner | __---_____
> Albatross Consulting Pty. Ltd. |----/ - \
> (A.C.N. 008 659 498) | /(@) ______---_
> Tel: (+61) 0500 83 82 81 | _________ \
> Fax: (+61) 0500 83 82 82 | ___________ |
> Http://www.rhyme.com.au | / \|
> | --________--
> PGP key available upon request, | /
> and from pgp5.ai.mit.edu:11371 |/
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026