Received: from localhost (unknown [200.46.204.183]) by developer.postgresql.org (Postfix) with ESMTP id 75EDA2E0040 for ; Wed, 11 Jun 2008 07:15:48 -0300 (ADT) Received: from developer.postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 74948-09 for ; Wed, 11 Jun 2008 07:15:40 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from anastacia.gransy.com (anastacia.gransy.com [89.187.130.100]) by developer.postgresql.org (Postfix) with ESMTP id EE35B2E0032 for ; Wed, 11 Jun 2008 07:15:43 -0300 (ADT) Received: from sq.gransy.com (localhost [127.0.0.1]) by anastacia.gransy.com (Postfix) with ESMTP id 558E231F7D0; Wed, 11 Jun 2008 12:15:41 +0200 (CEST) Received: from 217.77.161.17 (SquirrelMail authenticated user tv@fuzzy.cz) by sq.gransy.com with HTTP; Wed, 11 Jun 2008 12:15:41 +0200 (CEST) Message-ID: <13093.217.77.161.17.1213179341.squirrel@sq.gransy.com> In-Reply-To: <484FA134.7030807@cybertec.at> References: <484FA134.7030807@cybertec.at> Date: Wed, 11 Jun 2008 12:15:41 +0200 (CEST) Subject: Re: Scalability question From: tv@fuzzy.cz To: "Zoltan Boszormenyi" Cc: "PostgreSQL Performance" , "Hans-Juergen Schoenig" User-Agent: SquirrelMail/1.4.10a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-2 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200806/45 X-Sequence-Number: 30395 > Hi, > > I got a question about scalability in high volume insert situation > where the table has a primary key and several non-unique indexes > on other columns of the table. How does PostgreSQL behave > in terms of scalability? The high volume of inserts comes from > multiple transactions. > > Best regards, > Zoltán Böszörményi Well, that's a difficult question as it depends on hardware and software, but with a proper tunning the results may be very good. Just do the basic PostgreSQL tuning and then tune it for the INSERT performance if needed. It's difficult to give any other recommendations without a more detailed knowledge of the problem, but consider these hints: 1) move the pg_xlog to a separate drive (so it's linear) 2) move the table with large amount of inserts to a separate tablespace 3) minimize the amount of indexes etc. The basic rule is that each index adds some overhead to the insert, but it depends on datatype, etc. Just prepare some data to import, and run the insert with and without the indexes and compare the time. Tomas