Re: Why does query planner choose slower BitmapAnd ?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Seamus Abshere <seamus(at)abshere(dot)net>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, pgsql-general(at)postgresql(dot)org
Subject: Re: Why does query planner choose slower BitmapAnd ?
Date: 2016-02-22 17:24:30
Message-ID: 25640.1456161870@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Seamus Abshere <seamus(at)abshere(dot)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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2016-02-22 17:25:28 Re: Why does query planner choose slower BitmapAnd ?
Previous Message Seamus Abshere 2016-02-22 17:18:12 Re: Why does query planner choose slower BitmapAnd ?