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

Re: pg_dump & performance degradation

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Philip Warner <pjw(at)rhyme(dot)com(dot)au>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org, brianb-pggeneral(at)edsamail(dot)com
Subject: Re: pg_dump & performance degradation
Date: 2000-08-01 01:37:34
Message-ID: 200008010137.VAA18839@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-hackers
I do not think it is a good idea to add some sleep-ability to pg_dump
unless we can get a general agreement that this is a valuable feature.


> At 13:36 28/07/00 -0400, Tom Lane wrote:
> >Philip Warner <pjw(at)rhyme(dot)com(dot)au> writes:
> >> Well...pg_dump sits in a loop reading COPY output; my hope was to see how
> >> long the copy took, and then wait an appropriate amount of time. The dummy
> >> select works nicely as a sleep call, but I can't really tell how long to
> >> sleep without a sub-second timer, or something that tells me the time
> >> between two calls.
> >
> >Seems like just delaying for a user-specifiable number of microseconds
> >between blocks or lines of COPY output would get the job done. 
> 
> You're probably right; and if I can't trust setitimer, sigaction and pause,
> then I guess I have no choice.
> 
> 
> > I'm not
> >clear what the reason is for needing to measure anything --- the user is
> >going to be tweaking the parameter anyway to arrive at what he feels is
> >an acceptable overall system load from the backup operation, so how are
> >you making his life easier by varying the delay?
> ...
> >We do have an existing dependency on gettimeofday() in postgres.c's
> >ShowUsage(), so if you really feel a compulsion to measure then that's
> >what to use.  I don't see what it's buying you though.
> 
> 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. A
> simple 'wait 200ms' model would be fine for the former, but way too long
> for the latter.
> 
> >(AFAIR no one's ever asked for this before, so...)
> 
> like most of these things (at least for me), it is personally relevant: I
> also experience severe peformance degradation during backups.
> 
> I'll look at gettimeofday...
> 
> 
> ----------------------------------------------------------------
> 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   |/
> 


-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

In response to

pgsql-hackers by date

Next:From: Thomas SwanDate: 2000-08-01 01:42:21
Subject: Classes and Inheritance
Previous:From: Chris BitmeadDate: 2000-08-01 00:06:18
Subject: Re: Announcement: I'm joining Great Bridge

pgsql-general by date

Next:From: Bruce MomjianDate: 2000-08-01 01:48:41
Subject: Re: pg_dump & performance degradation
Previous:From: Tom LaneDate: 2000-08-01 01:30:10
Subject: Re: postgres perl DBI

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