Hello,

What is your statistics target?
What is your effective_cache_size?

Have you tried running the query as a cursor?

Sincerely,

Joshua D. Drake



Andrew Janian wrote:
I have run ANALYZE right before running this query.

I will run EXPLAIN ANALYZE when I can.  I started running the query when I sent 
the first email and it is still running.  Looke like it longer than an hour.

I will post the results of EXPLAIN ANALYZE in a few hours when I get them.

Thanks for all your help,

Andrew

-----Original Message-----
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 18, 2004 9:40 AM
To: Andrew Janian
Cc: [EMAIL PROTECTED]
Subject: Re: [PERFORM] Query Performance and IOWait



"Andrew Janian" <[EMAIL PROTECTED]> writes:

                                                                                
                                                                                
                                                                                
                                QUERY PLAN
Nested Loop IN Join  (cost=0.00..34047.29 rows=1 width=526)
 ->  Index Scan using mfi_log_time on mb_fix_message  (cost=0.00..22231.31 
rows=2539 width=526)
      Index Cond: ((msg_log_time > '2004-06-01 00:00:00'::timestamp without time 
zone) AND (msg_log_time < '2004-06-01 23:59:59.999'::timestamp without time zone))
      Filter: (((msg_message_type)::text = '8'::text) AND (((mb_raw_text)::text 
~~ '%39=1%'::text) OR ((mb_raw_text)::text ~~ '%39=2%'::text)))
 ->  Index Scan using mfi_client_ordid on mb_fix_message  (cost=0.00..445.56 
rows=1 width=18)
      Index Cond: (("outer".msg_client_order_id)::text = 
(mb_fix_message.msg_client_order_id)::text)
      Filter: ((msg_log_time >= '2004-06-01 00:00:00'::timestamp without time 
zone) AND (msg_log_time < '2004-06-01 13:30:00'::timestamp without time zone) AND 
((msg_message_type)::text = 'D'::text) OR ((msg_message_type)::text = 'G'::text)) AND 
((mb_ord_type)::text = '1'::text))


While running, this query produces 100% iowait usage on its processor and takes a ungodly amount of time (about an hour).


This plan looks fairly reasonable if the rowcount estimates are
accurate.  Have you ANALYZEd the table lately?  You might need to
bump up the statistics target for the msg_log_time column to improve
the quality of the estimates.  It would be useful to see EXPLAIN
ANALYZE results too (yes I know it'll take you an hour to get them...)

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org


--
Command Prompt, Inc., home of PostgreSQL Replication, and plPHP.
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com
Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL
begin:vcard
fn:Joshua D. Drake
n:Drake;Joshua D.
org:Command Prompt, Inc.
adr:;;PO Box 215;Cascade Locks;Oregon;97014;USA
email;internet:[EMAIL PROTECTED]
title:Consultant
tel;work:503-667-4564
tel;fax:503-210-0334
note:Command Prompt, Inc. is the largest and oldest US based commercial PostgreSQL support provider. We  provide the only commercially viable integrated PostgreSQL replication solution, but also custom programming, and support. We authored  the book Practical PostgreSQL, the procedural language plPHP, and adding trigger capability to plPerl.
x-mozilla-html:FALSE
url:http://www.commandprompt.com/
version:2.1
end:vcard

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
      joining column's datatypes do not match

Reply via email to