Re: Good/Bad query plans based on text criteria - Mailing list pgsql-performance

From Tom Lane
Subject Re: Good/Bad query plans based on text criteria
Whole thread Raw
In response to Good/Bad query plans based on text criteria  (JmH)
List pgsql-performance
JmH <> 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

pgsql-performance by date:

From: JmH
Subject: Good/Bad query plans based on text criteria
From: Dave Crooke
Subject: Re: JDBC question for PG 8.3.9