On Tue, Dec 20, 2016 at 2:13 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote: > 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?
Hmm, seems like you'd be paying the operator cost either way. No?
It looks so this cost is much more significant in index scan feature
