Re: More 8.2 client issues (Was: [Slow dump?) - Mailing list pgsql-performance

From Erik Jones
Subject Re: More 8.2 client issues (Was: [Slow dump?)
Date
Msg-id 459BEEB8.5050405@myemma.com
Whole thread Raw
In response to Re: More 8.2 client issues (Was: [Slow dump?)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: More 8.2 client issues (Was: [Slow dump?)
List pgsql-performance
Tom Lane wrote:
> Erik Jones <erik@myemma.com> writes:
>
>> Guillaume Smet wrote:
>>
>>> Could you set log_min_duration_statement=0 on your server and enable
>>>
>
>
>> Heh, unfortunately, setting log_min_duration_statement=0 would be a
>> total last resort as the last we counted (2 months ago) we were doing
>> approximately 3 million transactions per hour.
>>
>
> Do it just for the pg_dump:
>
>     export PGOPTIONS="--log_min_duration_statement=0"
>     pg_dump ...
>
> I don't think that the regex issue explains pg_dump being slow,
> unless perhaps you are making use of the table-selection switches?
>
That's a good idea, but first I'll still need to run it by my sysadmin
wrt space -- our dump files are around 22GB when we can let them finish
these days.  We do have plans to move off of the dump to a snapshot
backup strategy that will eventually lead to a PITR  warm-standby setup
but, first, we want to make sure we have a stable, fast, up-to-date
server -- our web servers are still connecting to the db via 8.1.4
client libs as given what we've seen of the track record for 8.2. client
libs on our setup, we're bit reticent to move the rest of the
application over.  While I wait to see what we can do about logging
everything during the dump I'll  probably  build 8.2 on a remote linux
machine and see how  connecting via those tools compares.

--
erik jones <erik@myemma.com>
software development
emma(r)


pgsql-performance by date:

Previous
From: "Jeremy Haile"
Date:
Subject: Performance of PostgreSQL on Windows vs Linux
Next
From: Tom Lane
Date:
Subject: Re: More 8.2 client issues (Was: [Slow dump?)