pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Richard Huxton <dev@archonet.com>
To: smiley2211 <smiley2211@yahoo.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Query is taking 5 HOURS to Complete on 8.1 version
Date: Tue, 03 Jul 2007 20:18:11 +0100
Message-ID: <468AA0F3.6030207@archonet.com> (raw)
In-Reply-To: <11418557.post@talk.nabble.com>
References: <11416966.post@talk.nabble.com>
	<11418557.post@talk.nabble.com>

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



view thread (11+ messages)  latest in thread

Message-ID: <468AA0F3.6030207@archonet.com>
Permalink:  ../468AA0F3.6030207@archonet.com/
Also on:    postgresql.org/message-id/468AA0F3.6030207@archonet.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: dev@archonet.com, smiley2211@yahoo.com
  Subject: Re: Query is taking 5 HOURS to Complete on 8.1 version
  In-Reply-To: <468AA0F3.6030207@archonet.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox