Re: [HACKERS] too low cost of Bitmap index scan

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: [HACKERS] too low cost of Bitmap index scan
Дата
Msg-id CAFj8pRCzra4y=ysQi3LPWnfDK=BYXQ_AxyH-rWTFwM3DbBH22w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] too low cost of Bitmap index scan  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Дерево обсуждения


2016-12-21 0:01 GMT+01:00 Tom Lane <tgl@sss.pgh.pa.us>:
Pavel Stehule <pavel.stehule@gmail.com> writes:
> I am trying to fix slow query on PostgreSQL 9.5.4.
> The data are almost in RAM

If it's all in RAM, you'd likely be well-served to lower random_page_cost.
It looks to me like the planner is estimating pretty accurately how many
heap fetches will be eliminated by using the extra index; where it's off
seems to be in the cost of those heap fetches relative to the index work.

When I decrease random page cost, then the cost of bitmapscan was decreased too

https://explain.depesz.com/s/7CAJ .. random page cost 2
https://explain.depesz.com/s/iEBW .. random page cost 2, bitmapscan off
https://explain.depesz.com/s/W4zw .. random page cost 2
https://explain.depesz.com/s/Gar .. random page cost 1, bitmapscan off

I played with other costs, but without any success, the cost of bitmapscan is significantly cheaper then index scan.

Regards

Pavel


                        regards, tom lane

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Petr Jelinek
Дата:
Сообщение: Re: [HACKERS] Logical decoding on standby
Следующее
От: Ants Aasma
Дата:
Сообщение: Re: [HACKERS] Replication slot xmin is not reset if HS feedback isturned off while standby is shut down