On Mon, Nov 11, 2013 at 1:48 PM, Jim Nasby <jnasby@xxxxxxxxx> wrote: > Postgres 9.1.9. > > explain analyze select min(insert_time) from cnu_stats.page_hits_raw ; > > QUERY PLAN > ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- > Result (cost=0.12..0.13 rows=1 width=0) (actual > time=257545.835..257545.836 rows=1 loops=1) > InitPlan 1 (returns $0) > -> Limit (cost=0.00..0.12 rows=1 width=8) (actual > time=257545.828..257545.829 rows=1 loops=1) > -> Index Scan using page_hits_raw_pkey on page_hits_raw > (cost=0.00..5445004.65 rows=47165480 width=8) (actual > time=257545.826..257545.826 rows=1 loops=1) > Index Cond: (insert_time IS NOT NULL) > Total runtime: 257545.881 ms > (6 rows) > > > I checked and there were no un-granted locks... but I have a hard time > believing it actually too 257 seconds to get 2 pages (one index, one heap) > back from our SAN. Try adding EXPLAIN (ANALYZE, BUFFERS). I am wondering if you are reading through a lot of pages addressing tuples not visible to the transaction. -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
