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 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/ -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
