X-Original-To: pgsql-performance-postgresql.org@postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 7BDFB9FA5BA for ; Thu, 22 Jun 2006 13:19:59 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 02447-09 for ; Thu, 22 Jun 2006 13:19:54 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id 4D0A49FA2F0 for ; Thu, 22 Jun 2006 13:19:54 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.6/8.13.6) with ESMTP id k5MGJrrC000694; Thu, 22 Jun 2006 12:19:53 -0400 (EDT) To: Ron St-Pierre cc: pgsql-performance@postgresql.org Subject: Re: Tuning New Server (slow function) In-reply-to: <44996C83.5040302@shaw.ca> References: <44996C83.5040302@shaw.ca> Comments: In-reply-to Ron St-Pierre message dated "Wed, 21 Jun 2006 08:57:55 -0700" Date: Thu, 22 Jun 2006 12:19:52 -0400 Message-ID: <693.1150993192@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200606/449 X-Sequence-Number: 19806 Ron St-Pierre writes: > We just purchased a new Dell PowerEdge 2800 (dual xeon, 8GB RAM, raid 4, > RHEL, postgres 8.1) and ported our old database over to it (single cpu, > 2GB RAM, no raid, postgres 7.4). Our apps perform great on it, however > some queries are super slow. One function in particular, which used to > take 15-30 minutes on the old server, has been running now for over 12 > hours: A fairly common gotcha in updating is to forget to ANALYZE all your tables after loading the data into the new server. My bet is that some of the queries in the function are using bad plans for lack of up-to-date statistics. If ANALYZEing and then starting a fresh session (to get rid of the function's cached plans) doesn't help, you'll need to do some comparison of EXPLAIN plans between old and new server to try to figure out where the problem is. regards, tom lane