Re: pg_dump & performance degradation

Philip Warner <pjw(at)rhyme(dot)com(dot)au> writes:
>> 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.

Seems like just delaying for a user-specifiable number of microseconds
between blocks or lines of COPY output would get the job done. 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?

> Would there be a portability problem with using setitimer, pause, &
> sigaction?

Signal behavior is not very portable, and I'd counsel against
introducing any new portability risks for what's fundamentally a pretty
third-order feature. (AFAIR no one's ever asked for this before, so...)
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.

regards, tom lane