On Sun, Oct 04, 2009 at 11:08:01AM -0400, Tom Lane wrote: > Sam Mason <sam@xxxxxxxxxxxxx> writes: > > On Sun, Oct 04, 2009 at 01:44:30AM -0700, tomrevam wrote: > >> -> Bitmap Index Scan on session_allocation_info_status_idx (cost=0.00..5.28 rows=1 width=0) (actual time=1619.652..1619.652 rows=51025 loops=1) > >> Index Cond: ((status)::text = 'active'::text) > >> -> Bitmap Index Scan on session_allocation_info_status_idx (cost=0.00..5.28 rows=1 width=0) (actual time=806.770..806.770 rows=46601 loops=1) > >> Index Cond: ((status)::text = 'setup'::text) > >> Total runtime: 4819.990 ms > > > Wow, that's quite a change in run time! Are you sure planner stats are > > being kept up to date? > > It's not the planner's fault. Note that the parent BitmapHeapScan is > still returning the same number of rows. Sorry, I chopped out too much context. Here's the "early" run, the estimated and real row counts look good to me: On Sun, Oct 04, 2009 at 01:44:30AM -0700, tomrevam wrote: > -> Bitmap Index Scan on session_allocation_info_status_idx (cost=0.00..48.93 rows=1555 width=0) (actual time=0.244..0.244 rows=1557 loops=1) > Index Cond: ((status)::text = 'active'::text) > -> Bitmap Index Scan on session_allocation_info_status_idx (cost=0.00..48.93 rows=1555 width=0) (actual time=0.181..0.181 rows=1609 loops=1) > Index Cond: ((status)::text = 'setup'::text) > Total runtime: 2.193 ms Or did I missing something else? -- Sam http://samason.me.uk/ -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
