Re: More 8.2 client issues (Was: [Slow dump?)
| От | Erik Jones |
|---|---|
| Тема | Re: More 8.2 client issues (Was: [Slow dump?) |
| Дата | |
| Msg-id | 459BEEB8.5050405@myemma.com обсуждение исходный текст |
| Ответ на | Re: More 8.2 client issues (Was: [Slow dump?) (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: More 8.2 client issues (Was: [Slow dump?)
|
| Список | 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 по дате отправления: