Re: Why does query planner choose slower BitmapAnd ?

From: Seamus Abshere <seamus(at)abshere(dot)net>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org
Subject: Re: Why does query planner choose slower BitmapAnd ?
Date: 2016-02-22 17:43:46
Message-ID: 1456163026.1010122.528467178.1C12E03A@webmail.messagingengine.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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?

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2016-02-22 17:47:30 Re: Why does query planner choose slower BitmapAnd ?
Previous Message Jeff Janes 2016-02-22 17:30:18 Re: Why does query planner choose slower BitmapAnd ?