Re: Why does query planner choose slower BitmapAnd ?

Поиск
Список
Период
Сортировка
От Seamus Abshere
Тема Re: Why does query planner choose slower BitmapAnd ?
Дата
Msg-id 1456163026.1010122.528467178.1C12E03A@webmail.messagingengine.com
обсуждение исходный текст
Ответ на Re: Why does query planner choose slower BitmapAnd ?  (Jeff Janes <jeff.janes@gmail.com>)
Ответы Re: Why does query planner choose slower BitmapAnd ?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Jeff Janes
Дата:
Сообщение: Re: Why does query planner choose slower BitmapAnd ?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Why does query planner choose slower BitmapAnd ?