Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 01FFBB5DBD5 for ; Mon, 27 Jun 2011 12:32:18 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 18862-01 for ; Mon, 27 Jun 2011 15:32:12 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from elizabeth.gransy.com (elizabeth.gransy.com [89.187.132.199]) by mail.postgresql.org (Postfix) with ESMTP id D2CFDB5DBCE for ; Mon, 27 Jun 2011 12:32:11 -0300 (ADT) Received: from sq.gransy.com (localhost [127.0.0.1]) by elizabeth.gransy.com (Postfix) with ESMTP id 0F6CB15E410C; Mon, 27 Jun 2011 17:32:10 +0200 (CEST) Received: from 85.160.214.34 (SquirrelMail authenticated user tv@fuzzy.cz) by sq.gransy.com with HTTP; Mon, 27 Jun 2011 17:32:10 +0200 Message-ID: <7d7f310e31bbaa62793e13897d889e1d.squirrel@sq.gransy.com> In-Reply-To: References: <4E084F71020000250003EC59@gw.wicourts.gov> Date: Mon, 27 Jun 2011 17:32:10 +0200 Subject: Re: Performance issue with Insert From: tv@fuzzy.cz To: "Jenish" Cc: "Kevin Grittner" , pgsql-performance@postgresql.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-10 required=5 tests=BAYES_00=-1.9 X-Spam-Level: X-Archive-Number: 201106/246 X-Sequence-Number: 44179 > Hi, > > DB : POSTGRES 8.4.8 > OS : Debian > HD : SAS 10k rpm > > Shared_buffer is 4096 25 % of RAM , effective_cache is 8GB 75% of RAM > > After insert trigger is again calling 2 more trigger and insert record in > another table depends on condition. > > with all trigger enable there are 8 insert and 32 updates(approx. update > is > depends on hierarchy) Hi, it's very difficult to give you reliable recommendations with this little info, but the triggers are obviously the bottleneck. We have no idea what queries are executed in them, but I guess there are some slow queries. Find out what queries are executed in the triggers, benchmark each of them and make them faster. Just don't forget that those SQL queries are executed as prepared statements, so they may behave a bit differently than plain queries. So use 'PREPARE' and 'EXPLAIN EXECUTE' to tune them. > Plz explain multiple connections. Current scenario application server is > sending all requests. PostgreSQL does not support parallel queries (i.e. a query distributed on multiple CPUs) so each query may use just a single CPU. If you're CPU bound (one CPU is 100% utilized but the other CPUs are idle), you can usually parallelize the workload on your own - just use multiple connections. But if you're using an application server and there are multiple connections used, this is not going to help you. How many connections are active at the same time? Are the CPUs idle or utilized? Tomas