Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id BF5C564FC8B for ; Thu, 27 Nov 2008 04:44:34 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 00186-08 for ; Thu, 27 Nov 2008 04:44:29 -0400 (AST) X-Greylist: delayed 00:06:39.011309 by SQLgrey-1.7.6 Received: from 2.mail-out.ovh.net (2.mail-out.ovh.net [91.121.26.226]) by mail.postgresql.org (Postfix) with SMTP id BAA9764FC92 for ; Thu, 27 Nov 2008 04:44:28 -0400 (AST) Received: (qmail 2505 invoked by uid 503); 27 Nov 2008 09:14:59 -0000 Received: from b7.ovh.net (HELO mail185.ha.ovh.net) (213.186.33.57) by 2.mail-out.ovh.net with SMTP; 27 Nov 2008 09:14:59 -0000 Received: from b0.ovh.net (HELO queue-out) (213.186.33.50) by b0.ovh.net with SMTP; 27 Nov 2008 08:37:37 -0000 Received: from par69-8-88-161-102-87.fbx.proxad.net (HELO soyouz) (88.161.102.87) by ns0.ovh.net with SMTP; 27 Nov 2008 08:37:35 -0000 Date: Thu, 27 Nov 2008 09:38:36 +0100 To: "Kevin Kempter" , pgsql-performance Subject: Re: performance tuning queries From: PFC Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 References: <200811262121.05463.kevin@kevinkempterllc.com> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <200811262121.05463.kevin@kevinkempterllc.com> User-Agent: Opera Mail/9.62 (Linux) X-Ovh-Tracer-Id: 6651535176632436257 X-Ovh-Remote: 88.161.102.87 (par69-8-88-161-102-87.fbx.proxad.net) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-Spam-Check: DONE|H 0.5/N X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200811/281 X-Sequence-Number: 32012 > First off, any thoughts per tuning inserts into large tables. I have a > large > table with an insert like this: > > insert into public.bigtab1 (text_col1, text_col2, id) values ... > > QUERY PLAN > ------------------------------------------ > Result (cost=0.00..0.01 rows=1 width=0) > (1 row) > > The query cost is low but this is one of the slowest statements per > pgfouine Possible Causes of slow inserts : - slow triggers ? - slow foreign key checks ? (missing index on referenced table ?) - functional index on a slow function ? - crummy hardware (5 MB/s RAID cards, etc) - too many indexes ? > Next we have a select count(*) that also one of the top offenders: > > select count(*) from public.tab3 where user_id=31 > and state='A' > and amount>0; > > QUERY PLAN > ----------------------------------------------------------------------------------------------------- > Aggregate (cost=3836.53..3836.54 rows=1 width=0) > -> Index Scan using order_user_indx ontab3 user_id > (cost=0.00..3834.29 > rows=897 width=0) > Index Cond: (idx_user_id = 31406948::numeric) > Filter: ((state = 'A'::bpchar) AND (amount > 0::numeric)) > (4 rows) > > We have an index on the user_id but not on the state or amount, > > add index to amount ? Can we see EXPLAIN ANALYZE ? In this case the ideal index would be multicolumn (user_id, state) or (user_id,amount) or (user_id,state,amount) but choosing between the 3 depends on your data... You could do : SELECT count(*), state, amount>0 FROM public.tab3 where user_id=31 GROUP BY state, amount>0; And post the results.