Received: from localhost (maia-5.hub.org [200.46.204.182]) by postgresql.org (Postfix) with ESMTP id EEFAC9FB6FA for ; Tue, 3 Jul 2007 16:18:31 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.182]) (amavisd-maia, port 10024) with ESMTP id 62250-02 for ; Tue, 3 Jul 2007 16:18:11 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from mail.metronet.co.uk (mail.metronet.co.uk [213.162.97.75]) by postgresql.org (Postfix) with ESMTP id 8D2A59FB51F for ; Tue, 3 Jul 2007 16:18:13 -0300 (ADT) Received: from server3.office.archonet.com (84-51-143-99.archon037.adsl.metronet.co.uk [84.51.143.99]) by smtp.metronet.co.uk (MetroNet Mail) with ESMTP id D50B114379B; Tue, 3 Jul 2007 20:18:11 +0100 (BST) Received: from [192.168.1.36] (dell36.office.archonet.com [192.168.1.36]) by server3.office.archonet.com (Postfix) with ESMTP id CA69827410E; Tue, 3 Jul 2007 20:18:11 +0100 (BST) Message-ID: <468AA0F3.6030207@archonet.com> Date: Tue, 03 Jul 2007 20:18:11 +0100 From: Richard Huxton User-Agent: Thunderbird 2.0.0.0 (X11/20070326) MIME-Version: 1.0 To: smiley2211 Cc: pgsql-performance@postgresql.org Subject: Re: Query is taking 5 HOURS to Complete on 8.1 version References: <11416966.post@talk.nabble.com> <11418557.post@talk.nabble.com> In-Reply-To: <11418557.post@talk.nabble.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200707/20 X-Sequence-Number: 25704 smiley2211 wrote: > Here is the EXPLAIN after I changed some conf file - now I am running another > EXPLAIN ANALYZE which may take 5 or more hours to complete :,( > > effective_cache = 170000 Why has effective_cache changed from 80,000 to 170,000 - have you stopped running some other application? > enable_seqscan = on > enable _bitmapscan = on Why were these disabled before? What were you trying to achieve? What has now changed? > QUERY PLAN You still haven't supplied the query. However, looking at the explain I'd guess there's a lot of sorting going on? You might want to increase work_mem just for this query: SET work_mem = ...; SELECT ... However, that's just a blind guess because you haven't supplied the absolutely vital information: 1. The query 2. An idea of how many rows are in the relevant tables 3. The "I have vacuumed and analysed recently" disclaimer 4. The explain analyse (which you are running - good, make sure you save a copy of it somwhere). Even then it'll be difficult to get a quick answer because it looks like a large query. So - you can speed things along by looking for oddities yourself. The explain analyse will have two values for "rows" on each line, the predicted and the actual - look for where they are wildly different. If the planner is expecting 2 matches and seeing 2000 it might make the wrong choice. You can usually cut down the large query to test just this section. Then you might want to read up about "ALTER TABLE ... SET STATISTICS" - that might give the planner more to work with. The other thing to look for is the time. The explain analyse has two figures for "actual time". These are startup and total time for that node (if "loops" is > 1 then multiply the time by the number of loop iterations). It might be there are one or two nodes that are taking a long time and we can find out why then. HTH -- Richard Huxton Archonet Ltd