Re: performance regression in 9.2 when loading lots of small tables

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

In response to

Responses

Browse pgsql-hackers by date

  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)