2016-12-20 13:55 GMT+01:00 Robert Haas <robertmh...@gmail.com>: > On Tue, Dec 20, 2016 at 2:13 AM, Pavel Stehule <pavel.steh...@gmail.com> > wrote: > > 2016-12-19 23:28 GMT+01:00 Robert Haas <robertmh...@gmail.com>: > >> On Sat, Dec 17, 2016 at 3:30 AM, Pavel Stehule <pavel.steh...@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 Pavel > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >