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

From Seamus Abshere
Subject Re: Why does query planner choose slower BitmapAnd ?
Date
Msg-id 1456163026.1010122.528467178.1C12E03A@webmail.messagingengine.com
Whole thread Raw
In response to Re: Why does query planner choose slower BitmapAnd ?  (Jeff Janes <jeff.janes@gmail.com>)
Responses Re: Why does query planner choose slower BitmapAnd ?
List pgsql-general
On Mon, Feb 22, 2016, at 02:30 PM, Jeff Janes wrote:
> It charges 0.1 CPU_operator_cost, while reality seemed to be more like 6 CPU_operator_cost.

fdy=> select name, setting, boot_val from pg_settings where name ~
'cpu';
         name         | setting | boot_val
----------------------+---------+----------
 cpu_index_tuple_cost | 0.005   | 0.005
 cpu_operator_cost    | 0.0025  | 0.0025
 cpu_tuple_cost       | 0.01    | 0.01
(3 rows)

Inspired, I changed cpu_index_tuple_cost to 0.1 (default: 0.005). It
"fixed" my problem by preventing the BitmapAnd.

Is this dangerous?


pgsql-general by date:

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