Re: performance regression in 9.2 when loading lots of small tables - Mailing list pgsql-hackers

From Robert Haas
Subject Re: performance regression in 9.2 when loading lots of small tables
Date
Msg-id CA+TgmoafFtHASO38ti+5tnL-5UAp=Y2_EPcqwaRSFaTpa3yqFQ@mail.gmail.com
Whole thread Raw
In response to Re: performance regression in 9.2 when loading lots of small tables  (Jeff Janes <jeff.janes@gmail.com>)
Responses Re: performance regression in 9.2 when loading lots of small tables  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-hackers
On Tue, Jun 19, 2012 at 10:56 PM, Jeff Janes <jeff.janes@gmail.com> wrote:
> But in the 9.2 branch, the slow phenotype was re-introduced in
> 1575fbcb795fc331f4, although perhaps the details of who is locking
> what differs.  I haven't yet sorted that out.

It very much does.  That commit prevents people from creating a
relation in - or renaming a relation into - a schema that is being
concurrently dropped, which in previous releases would have resulted
in inconsistent catalog contents.  I admit that it harms your test
case, but how likely is it that someone is going to put every single
table into its own schema?  And have shared_buffers low enough for
this to be the dominant cost?  I think in real-world scenarios this
isn't going to be a problem - although, of course, making the lock
manager faster would be nifty if we can do it, and this might be a
good test case.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [PATCH 04/16] Add embedded list interface (header only)
Next
From: Tom Lane
Date:
Subject: Re: [PATCH 10/16] Introduce the concept that wal has a 'origin' node