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

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: [HACKERS] too low cost of Bitmap index scan
Дата
Msg-id CAFj8pRAF6RXTW4m0VKr4wnrMzuAGzQuZuN=O4OVsBO88BnJpag@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] too low cost of Bitmap index scan  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [HACKERS] too low cost of Bitmap index scan  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers


2016-12-19 23:28 GMT+01:00 Robert Haas <robertmhaas@gmail.com>:
On Sat, Dec 17, 2016 at 3:30 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> ->  Bitmap Heap Scan on "Zasilka"  (cost=5097.39..5670.64 rows=1 width=12)
> (actual time=62.253..62.400 rows=3 loops=231)
...
> When I disable bitmap scan, then the query is 6x time faster
....
>    ->  Index Scan using "Zasilka_idx_Dopravce" on "Zasilka"
> (cost=0.00..30489.04 rows=1 width=12) (actual time=15.651..17.187 rows=3
> loops=231)
>         Index Cond: ("Dopravce" = "Dopravce_Ridic_1"."ID")
>        Filter: (("StavDatum" > (now() - '10 days'::interval)) AND (("Stav" =
> 34) OR ("Stav" = 29) OR ("Stav" = 180) OR ("Stav" = 213) OR ("Stav" = 46) OR
> (("Produkt" = 33) AND ("Stav" = 179)) OR ((("ZpetnaZasilka" = '-1'::integer)
> OR ("PrimaZasilka" = '-1'::integer)) AND ("Stav" = 40))))
>         Rows Removed by Filter: 7596

I'm not sure, but my guess would be that the query planner isn't
getting a very accurate selectivity estimate for that giant filter
condition, and that's why the cost estimate is off.

maybe operator cost is too high?

Regards

Pavel


--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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

Предыдущее
От: Erik Rijkers
Дата:
Сообщение: Re: [HACKERS] Logical Replication WIP
Следующее
От: Beena Emerson
Дата:
Сообщение: Re: [HACKERS] increasing the default WAL segment size