Re: pg_dump & performance degradation
От | Philip Warner |
---|---|
Тема | Re: pg_dump & performance degradation |
Дата | |
Msg-id | 3.0.5.32.20000729025257.01e1e480@mail.rhyme.com.au обсуждение исходный текст |
Ответ на | Re: pg_dump & performance degradation (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pg_dump & performance degradation
|
Список | pgsql-hackers |
At 12:22 28/07/00 -0400, Tom Lane wrote: >Philip Warner <pjw@rhyme.com.au> writes: >> Brian Baquiran in the [GENERAL] list recently asked if it was possible to >> 'throttle-down' pg_dump so that it did not cause an IO bottleneck when >> copying large tables. > >> Can anyone see a reason not to pause periodically? > >Because it'd slow things down? Cute. >> Finally, can anyone point me to the most portable subsecond timer routines? > >You do not want a timer routine, you want a delay. I think using a >dummy select() with a timeout parameter might be the most portable way. >Anyway we've used it for a long time --- see the spinlock backoff code >in s_lock.c. 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. Would there be a portability problem with using setitimer, pause, & sigaction? ---------------------------------------------------------------- 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 |/
В списке pgsql-hackers по дате отправления: