Re: pg_dump & performance degradation

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Philip Warner <pjw(at)rhyme(dot)com(dot)au>
Cc: pgsql-hackers(at)postgresql(dot)org, brianb-pggeneral(at)edsamail(dot)com
Subject: Re: pg_dump & performance degradation
Date: 2000-07-29 04:57:46
Message-ID: 8590.964846666@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Philip Warner <pjw(at)rhyme(dot)com(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Philip Warner 2000-07-29 05:58:17 Re: pg_dump & performance degradation
Previous Message Tom Lane 2000-07-29 04:39:17 Hmm ... shouldn't path_distance be MIN distance not MAX distance?

Browse pgsql-hackers by date

  From Date Subject
Next Message Denis Perchine 2000-07-29 05:03:54 Re: Fwd: Postgres update
Previous Message Tom Lane 2000-07-29 04:39:17 Hmm ... shouldn't path_distance be MIN distance not MAX distance?