Skip site navigation (1) Skip section navigation (2)

Re: pg_dump & performance degradation

From: Philip Warner <pjw(at)rhyme(dot)com(dot)au>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Don Baccus <dhogaza(at)pacifier(dot)com>, pgsql-hackers(at)postgresql(dot)org, brianb-pggeneral(at)edsamail(dot)com
Subject: Re: pg_dump & performance degradation
Date: 2000-08-01 03:06:51
Message-ID: 3.0.5.32.20000801130651.02f0c600@mail.rhyme.com.au (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-hackers
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   |/

In response to

Responses

pgsql-hackers by date

Next:From: hstengerDate: 2000-08-01 03:33:38
Subject: Re: Announcement: I'm joining Great Bridge
Previous:From: The Hermit HackerDate: 2000-08-01 02:09:23
Subject: Re: Anyone care about type "filename" ?

pgsql-general by date

Next:From: Cheng KaiDate: 2000-08-01 03:41:32
Subject: How to alter the size of a column
Previous:From: Ian TurnerDate: 2000-08-01 02:17:30
Subject: Re: Replication options in Postgres

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group