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
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 ? |