On Tue, Dec 4, 2012 at 7:27 AM, Claudio Freire <klaussfre...@gmail.com> wrote: > On Tue, Dec 4, 2012 at 12:06 PM, <postgre...@foo.me.uk> wrote: >> Slow version with bitmapscan enabled: http://explain.depesz.com/s/6I7 >> Fast version with bitmapscan disabled: http://explain.depesz.com/s/4MWG > > If you check the "fast" plan, it has a higher cost compared against > the "slow" plan. > > The difference between cost estimation and actual cost of your > queries, under relatively precise row estimates, seems to suggest your > e_c_s or r_p_c aren't a reflection of your hardware's performance.
But the row estimates are not precise at the top of the join/filter. It thinks there will 2120 rows, but there are only 11. So it seems like there is a negative correlation between the two tables which is not recognized. > First, make sure caching isn't interfering with your results. Run each > query several times. If that is not how the production system works (running the same query over and over) then you want to model the cold cache, not the hot one. But in any case, the posted explains indicates that all buffers were cached. Cheers, Jeff -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
