JmH <jason.height@xxxxxxxxx> 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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
