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.652rows=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.770rows=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 expecting a *single* row back from an index
scan of "session_allocation_info_status_idx" when looking for "active"
and a single row when looking for "setup" but gets 51025 and 46601 rows
back respectively. These are a *long* way out and would explain why it's
taking an inordinate amount of time.
If you try running "analyze session_allocation_info" and then seeing
what changes it would be interesting. I'd try to get the "rows=n"
numbers to be in the same order of magnitude in the estimates and in the
actual run time. Improving stats targets helps in some situations, but
may not here:
http://www.postgresql.org/docs/current/static/sql-altertable.html
Something like:
alter table session_allocation_info alter status set statistics 200;
--
Sam http://samason.me.uk/
