Re: pg_dump & performance degradation

At 21:48 31/07/00 -0400, Bruce Momjian wrote:
>> It would be a bad idea to nice down a backend anyway, if the intent is
>> to speed up other backends.  The Unix scheduler has no idea about
>> application-level locking, so you'll get priority-inversion problems:
>> once the nice'd backend has acquired any sort of lock, other backends
>> that may be waiting for that lock are at the mercy of the low priority
>> setting.  In effect, your entire database setup may be running at the
>> nice'd priority relative to anything else on the system.
>> 
>> I think Philip's idea of adding some delays into pg_dump is a reasonable
>> answer.  I'm just recommending a KISS approach to implementing the
>> delay, in the absence of evidence that a more complex mechanism will
>> actually buy anything...
>
>I am worried about feature creep here.

I agree; it's definitely a non-critical feature. But then, it is only 80
lines of code in one place (including 28 non-code lines). I am not totally
happy with the results it produces, so I have no objection to removing it
all. I just need some more general feedback...


>I can accept it as a config.h flag, 

You mean stick it in a bunch of ifdefs? What is the gain there?


>but it seems
>publishing it as a pg_dump flag is just way too complicated for users.

I've missed something, obviously. What is the problem here?


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