Re: pg_dump & performance degradation - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_dump & performance degradation
Date
Msg-id 8590.964846666@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_dump & performance degradation  (Philip Warner <pjw@rhyme.com.au>)
Responses Re: pg_dump & performance degradation  (Philip Warner <pjw@rhyme.com.au>)
List pgsql-hackers
Philip Warner <pjw@rhyme.com.au> writes:
> 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.

But ... but ... you have no idea at all how much time the backend has
expended to provide you with those rows, nor how much of the elapsed
time was used up by unrelated processes.  It's pointless to suppose
that you are regulating system load this way --- and I maintain that
system load is what the dbadmin would really like to regulate.

You may as well keep it simple and not introduce unpredictable
dependencies into the behavior of the feature.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Hmm ... shouldn't path_distance be MIN distance not MAX distance?
Next
From: Denis Perchine
Date:
Subject: Re: Fwd: Postgres update