Received: from localhost (unknown [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id A28AF9F9DB7 for ; Fri, 21 Sep 2007 11:08:08 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024) with ESMTP id 49914-03 for ; Fri, 21 Sep 2007 11:07:43 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from globalrelay.com (mail1.globalrelay.com [204.92.49.200]) by postgresql.org (Postfix) with ESMTP id 724849F9952 for ; Fri, 21 Sep 2007 11:07:52 -0300 (ADT) X-Virus-Scanned: Scanned by GRC-AntiVirus Gateway Received: from [63.231.179.95] (HELO davedell) by globalrelay.com (CommuniGate Pro SMTP 4.2.3) with ESMTP id 158173185; Fri, 21 Sep 2007 14:07:50 +0000 From: "Dave Dutcher" To: "'smiley2211'" , References: <12803859.post@talk.nabble.com> <55480.192.121.104.48.1190354307.squirrel@zigo.dhs.org> <12820410.post@talk.nabble.com> Subject: Re: Upgraded from 7.4 to 8.1.4 QUERIES NOW SLOW!!! Date: Fri, 21 Sep 2007 09:07:49 -0500 Message-ID: <01ba01c7fc58$cb346a40$cb00a8c0@tridecap.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acf8Um2eugxz0sj5QuOC1yvWnekLmgAAvUrQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <12820410.post@talk.nabble.com> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200709/365 X-Sequence-Number: 26910 >From: smiley2211 >Subject: Re: [PERFORM] Upgraded from 7.4 to 8.1.4 QUERIES NOW SLOW!!! > >-> Seq Scan on encounters_questions_answers eqa >(cost=100000000.00..100007608.66 rows=464766 width=8) (actual >time=0.003..735.934 rows=464766 loop >s=7430) It looks like enable_seqscan is set to false. For some reason that might have worked on 7.4, but I would try turning that back on for 8.1. Sequential scans aren't always bad, sometimes they are faster than index scans. I would first try running the system with all the enable_* settings on. If you can't turn on logging its going to be very hard to track down the problem. The easiest way to track down a problem normally is to set log_min_duration to something like 2000ms. Then Postgres will log all slow queries. Then you can run EXPLAIN ANALYZE on the slow queries to find the problem. I think Carlos had a good idea when he asked about the encoding on the new server vs the old. Does your application use the like keyword to compare text fields? If so, you might need to create indexes which use the text_pattern_ops operator classes. With unicode postgres cannot use an index scan for a query like SELECT * FROM foo WHERE name LIKE 'Bob%' unless there is an index like CREATE INDEX name_index ON foo (name text_pattern_ops). However if you are not using like queries, then this is not your problem. More on operator classes: http://www.postgresql.org/docs/8.1/interactive/indexes-opclass.html Dave