Re: Horrific time for getting 1 record from an index?

From: Daniel Farina <daniel(at)heroku(dot)com>
To: Jim Nasby <jnasby(at)enova(dot)com>
Cc: "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Horrific time for getting 1 record from an index?
Date: 2013-11-11 21:51:40
Message-ID: CAAZKuFaroDOtTj1MiZYmv9ZuHck_LQ-B2LjP_gDotqRPXtofMg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Mon, Nov 11, 2013 at 1:48 PM, Jim Nasby <jnasby(at)enova(dot)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.

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Jim Nasby 2013-11-11 21:57:47 Re: Horrific time for getting 1 record from an index?
Previous Message Jim Nasby 2013-11-11 21:48:09 Horrific time for getting 1 record from an index?