Thanks Tom The time difference did distract me from the issue. Switching Seq Scan to off reduced the runtime greatly, so I am now adjusting the effective_cache_size, random_page_cost settings to favor indexes over Seq Scans.
Regards, Tim -----Original Message----- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: Tuesday, 3 October 2006 1:50 PM To: Tim Truman Cc: 'Dave Dutcher'; pgsql-performance@postgresql.org Subject: Re: [PERFORM] Forcing the use of particular execution plans "Tim Truman" <[EMAIL PROTECTED]> writes: > Here is an "explain analyze" for the query that performs slowly, This shows that the planner is exactly correct in thinking that all the runtime is going into the seqscan on transaction: > "Aggregate (cost=88256.32..88256.32 rows=1 width=0) (actual > time=55829.000..55829.000 rows=1 loops=1)" > ... > " -> Seq Scan on "transaction" t > (cost=0.00..87061.04 rows=1630 width=349) (actual time=234.000..55797.000 > rows=200 loops=1)" > " Filter: ((transaction_date >= > '2005-01-01'::date) AND (transaction_date <= '2006-09-25'::date) AND > ((credit_card_no)::text ~~ '4564%549'::text))" Since that component of the plan was identical in your two original plans ("desired" and "undesired") it seems pretty clear that you have not correctly identified what your problem is. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
