Re: pg_dump & performance degradation

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_dump & performance degradation
Дата
Msg-id 8590.964846666@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pg_dump & performance degradation  (Philip Warner <pjw@rhyme.com.au>)
Ответы Re: pg_dump & performance degradation  (Philip Warner <pjw@rhyme.com.au>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Hmm ... shouldn't path_distance be MIN distance not MAX distance?
Следующее
От: Denis Perchine
Дата:
Сообщение: Re: Fwd: Postgres update