Re: Why does query planner choose slower BitmapAnd ? - Mailing list pgsql-general

From Tom Lane
Subject Re: Why does query planner choose slower BitmapAnd ?
Date
Msg-id 25640.1456161870@sss.pgh.pa.us
Whole thread Raw
In response to Re: Why does query planner choose slower BitmapAnd ?  (Seamus Abshere <seamus@abshere.net>)
List pgsql-general
Seamus Abshere <seamus@abshere.net> writes:
> Is there any other way to differentiate the 2 index scans? FWIW, 10% of
> houses are phoneable, 0.2% are in the city. (Maybe I'm just supposed to
> drop the index like Tom said.)

Hm.  10% is above the threshold where I'd usually think that an indexscan
could beat a seqscan, so dropping the "phoneable" index is definitely
something you should consider, especially if updates on this table are
frequent (because you're paying to update the index too).

However, I'd still counsel fooling with the cpu cost parameters first.
Alternatively, you could leave those at defaults and set random_page_cost
and seq_page_cost to 0.1 to 0.5 or so, which would net out to the same
effect (charging more for CPU relative to I/O) though with different
absolute cost numbers.

            regards, tom lane


pgsql-general by date:

Previous
From: Seamus Abshere
Date:
Subject: Re: Why does query planner choose slower BitmapAnd ?
Next
From: Tom Lane
Date:
Subject: Re: Why does query planner choose slower BitmapAnd ?