X-Original-To: pgsql-performance-postgresql.org@postgresql.org Received: from localhost (wm.hub.org [200.46.204.128]) by postgresql.org (Postfix) with ESMTP id D2A0A9FB278 for ; Tue, 8 Aug 2006 09:14:39 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.128]) (amavisd-new, port 10024) with ESMTP id 93536-08 for ; Tue, 8 Aug 2006 12:14:36 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey- Received: from kenobi.snowman.net (kenobi.snowman.net [70.84.9.186]) by postgresql.org (Postfix) with ESMTP id 836D59FB24E for ; Tue, 8 Aug 2006 09:14:36 -0300 (ADT) Received: by kenobi.snowman.net (Postfix, from userid 1000) id 303CA58047; Tue, 8 Aug 2006 07:14:35 -0500 (CDT) Date: Tue, 8 Aug 2006 08:14:35 -0400 From: Stephen Frost To: Alex Turner Cc: Alvaro Nunes Melo , pgsql-performance@postgresql.org Subject: Re: Hardware upgraded but performance still ain't good enough Message-ID: <20060808121435.GM20016@kenobi.snowman.net> Mail-Followup-To: Alex Turner , Alvaro Nunes Melo , pgsql-performance@postgresql.org References: <44D7B958.6030004@atua.com.br> <33c6269f0608072333o67ab6adei29095091718901dc@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Kpsb9uGLH42Key6t" Content-Disposition: inline In-Reply-To: <33c6269f0608072333o67ab6adei29095091718901dc@mail.gmail.com> X-Editor: Vim http://www.vim.org/ X-Info: http://www.snowman.net X-Operating-System: Linux/2.6.16-2-vserver-686 (i686) X-Uptime: 08:07:40 up 44 days, 2:04, 14 users, load average: 0.65, 0.79, 0.84 User-Agent: Mutt/1.5.11+cvs20060403 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests= X-Spam-Level: X-Archive-Number: 200608/98 X-Sequence-Number: 20283 --Kpsb9uGLH42Key6t Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Alvaro, * Alex Turner (armtuk@gmail.com) wrote: > The other thing is you will probably want to turn on stats in postgres to > figure out which queries are the bad ones (does anyone have good docs posted > for this?). Once you have identified the bad queries, you can explain > analyze them, and figure out why they suck. Given your position, this might be the best approach to take to find some 'low-hanging fruit'. Do you have queries which are complex in some way? Do you have many long-open transactions? If you're doing more than simple queries then you may want to explain analyze the more complex ones and try to speed them up. If you run into trouble understanding the output or how to improve it then post it here (with as much info as you can, schema definitions, the query, the explain analyze results, etc) and we can help. top/iostat/vmstat are very useful tools too and can help with hardware decisions but you probably want to review your queries and make sure the database is performing as best it can with the setup you have today before throwing more hardware at it. Thanks, Stephen --Kpsb9uGLH42Key6t Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFE2IArrzgMPqB3kigRAlLGAJ4ySSrMSHf9B+LKcuXnkiv/QAWsDQCfddW9 r8t4/iE3AoaoQGfY1UGXPLk= =BC8o -----END PGP SIGNATURE----- --Kpsb9uGLH42Key6t--