Re: Forcing the use of particular execution plans

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Tim Truman" <tim(at)advam(dot)com>
Cc: "'Dave Dutcher'" <dave(at)tridecap(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Forcing the use of particular execution plans
Date: 2006-10-03 04:19:39
Message-ID: 19401.1159849179@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

"Tim Truman" <tim(at)advam(dot)com> 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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Tim Truman 2006-10-03 06:51:01 Re: Forcing the use of particular execution plans
Previous Message Tim Truman 2006-10-03 03:59:37 Re: Forcing the use of particular execution plans