Re: pg_dump and thousands of schemas

From: Tatsuo Ishii <ishii(at)postgresql(dot)org>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: pg_dump and thousands of schemas
Date: 2012-05-30 09:06:20
Message-ID: 20120530.180620.600165924826262795.t-ishii@sraoss.co.jp
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

> Yeah, Jeff's experiments indicated that the remaining bottleneck is lock
> management in the server. What I fixed so far on the pg_dump side
> should be enough to let partial dumps run at reasonable speed even if
> the whole database contains many tables. But if psql is taking
> AccessShareLock on lots of tables, there's still a problem.

Ok, I modified the part of pg_dump where tremendous number of LOCK
TABLE are issued. I replace them with single LOCK TABLE with multiple
tables. With 100k tables LOCK statements took 13 minutes in total, now
it only takes 3 seconds. Comments?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp

Attachment Content-Type Size
pg_dump.diff text/x-patch 1.6 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2012-05-30 09:32:42 Re: Bug in new buffering GiST build code
Previous Message Heikki Linnakangas 2012-05-30 09:01:51 Re: Bug in new buffering GiST build code

Browse pgsql-performance by date

  From Date Subject
Next Message Murat Tasan 2012-05-30 17:57:43 does the query planner consider work_mem?
Previous Message Tatsuo Ishii 2012-05-30 00:58:16 Re: pg_dump and thousands of schemas