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