From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | JmH <jason(dot)height(at)gmail(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Good/Bad query plans based on text criteria |
Date: | 2010-04-15 02:42:21 |
Message-ID: | 21178.1271299341@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
JmH <jason(dot)height(at)gmail(dot)com> writes:
> I am struggling to understand why for certain criteria that i supply for a
> query alters the the query plan. In my "good" case i can see that an index
> is used, in my bad case where i only change the text value of the criteria,
> but not the criteria itslef (ie change/add the conditions) a hbitmap heap
> scan of the table is performed.
I think you're jumping to conclusions. The second plan is processing
about 100 times as many rows, because the WHERE conditions are much less
selective. A change in plan is entirely appropriate.
It might be that you need to change planner parameters (particularly
random_page_cost/seq_page_cost) to more nearly approximate the operating
conditions of your database, but I'd recommend being very cautious about
doing so on the basis of a small number of example queries. In
particular it's easy to fall into the trap of optimizing for
fully-cached scenarios because repeatedly trying the same example
results in touching only already-cached data --- but that might or might
not be reflective of your whole workload.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Crooke | 2010-04-15 03:03:09 | Re: JDBC question for PG 8.3.9 |
Previous Message | JmH | 2010-04-15 01:45:45 | Good/Bad query plans based on text criteria |