Re: pg_dump without explicit table locking
От | Jim Nasby |
---|---|
Тема | Re: pg_dump without explicit table locking |
Дата | |
Msg-id | 53277C57.4040404@nasby.net обсуждение исходный текст |
Ответ на | Re: pg_dump without explicit table locking (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pg_dump without explicit table locking
|
Список | pgsql-hackers |
On 3/17/14, 8:47 AM, Tom Lane wrote: > Pavel Stehule <pavel.stehule@gmail.com> writes: >> 2014-03-17 12:52 GMT+01:00 Jürgen Strobel <juergen+pg@strobel.info>: >>> I've googled the problem and there seem to be more people with similar >>> problems, so I made this a command line option --no-table-locks and >>> wrapped it up in as nice a patch against github/master as I can manage >>> (and I didn't use C for a long time). I hope you find it useful. > >> Joe Conway sent me a tip so commit eeb6f37d89fc60c6449ca12ef9e914 >> 91069369cb significantly decrease a time necessary for locking. So it can >> help to. > > Indeed. I think there's zero chance that we'd accept the patch as > proposed. If there's still a performance problem in HEAD, we'd look > for some other way to improve matters more. > > (Note that this is only one of assorted O(N^2) behaviors in older versions > of pg_dump; we've gradually stamped them out over time.) On that note, it's recommended that when you are taking a backup to restore into a newer version of Postgres you create thedump using the NEWER version of pg_dump, not the old one. -- Jim C. Nasby, Data Architect jim@nasby.net 512.569.9461 (cell) http://jim.nasby.net
В списке pgsql-hackers по дате отправления: