On Fri, Nov 9, 2012 at 10:50 AM, Jeff Janes <jeff.ja...@gmail.com> wrote: > On Thu, Nov 8, 2012 at 9:50 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Jeff Janes <jeff.ja...@gmail.com> writes: >>> Are sure the server you are dumping out of is head? >> >> I experimented a bit with dumping/restoring 16000 tables matching >> Bruce's test case (ie, one serial column apiece). The pg_dump profile >> seems fairly flat, without any easy optimization targets. But >> restoring the dump script shows a rather interesting backend profile: >> >> samples % image name symbol name >> 30861 39.6289 postgres AtEOXact_RelationCache >> 9911 12.7268 postgres hash_seq_search > ... >> >> There are at least three ways we could whack that mole: >> >> * Run the psql script in --single-transaction mode, as I was mumbling >> about the other day. If we were doing AtEOXact_RelationCache only once, >> rather than once per CREATE TABLE statement, it wouldn't be a problem. >> Easy but has only a narrow scope of applicability. > > That is effective when loading into 9.3 (assuming you make > max_locks_per_transaction large enough). But when loading into <9.3, > using --single-transaction will evoke the quadratic behavior in the > resource owner/lock table and make things worse rather than better.
Using --single-transaction gets around the AtEOXact_RelationCache quadratic, but it activates another quadratic behavior, this one in "get_tabstat_entry". That is a good trade-off because that one has a lower constant, but it is still going to bite. Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
