Message-ID: <52815099.4080409@enova.com>
Date: Mon, 11 Nov 2013 15:48:09 -0600
From: Jim Nasby <jnasby@enova.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8;
 rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: "pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Subject: Horrific time for getting 1 record from an index?
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

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.

Am I missing something here?
-- 
Jim Nasby, Lead Data Architect   (512) 569-9461


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance