From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: performance regression in 9.2 when loading lots of small tables |
Date: | 2012-06-20 03:06:20 |
Message-ID: | CA+TgmoafFtHASO38ti+5tnL-5UAp=Y2_EPcqwaRSFaTpa3yqFQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jun 19, 2012 at 10:56 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-06-20 03:26:45 | Re: [PATCH 10/16] Introduce the concept that wal has a 'origin' node |
Previous Message | Robert Haas | 2012-06-20 03:01:16 | Re: [PATCH 04/16] Add embedded list interface (header only) |