Re: Horrific time for getting 1 record from an index?
От | Daniel Farina |
---|---|
Тема | Re: Horrific time for getting 1 record from an index? |
Дата | |
Msg-id | CAAZKuFaroDOtTj1MiZYmv9ZuHck_LQ-B2LjP_gDotqRPXtofMg@mail.gmail.com обсуждение исходный текст |
Ответ на | Horrific time for getting 1 record from an index? (Jim Nasby <jnasby@enova.com>) |
Ответы |
Re: Horrific time for getting 1 record from an index?
|
Список | pgsql-performance |
On Mon, Nov 11, 2013 at 1:48 PM, Jim Nasby <jnasby@enova.com> 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.
В списке pgsql-performance по дате отправления: