From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Jürgen Strobel <juergen+pg(at)strobel(dot)info>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_dump without explicit table locking |
Date: | 2014-03-17 13:47:43 |
Message-ID: | 6388.1395064063@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> 2014-03-17 12:52 GMT+01:00 Jrgen Strobel <juergen+pg(at)strobel(dot)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.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2014-03-17 13:59:09 | Re: Archive recovery won't be completed on some situation. |
Previous Message | Alvaro Herrera | 2014-03-17 13:44:56 | Re: HEAD seems to generate larger WAL regarding GIN index |