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
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? |
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? |