Quantcast
Channel: Question and Answer » postgresql
Viewing all articles
Browse latest Browse all 1138

Slow index scans in large table (PostgreSQL 9.2)

$
0
0

I’m having trouble with slow queries on a relatively large table (200+ million rows). I’m trying anything crazy, just add historic values. Below is the query and the query plan output.

I sadly expect that disk access is the issue here, since the table isn’t in memory all the time.

EXPLAIN ANALYZE 
SELECT SUM("value") 
FROM "energy_energyentry" 
WHERE 
  "prop_id"=82411 
  AND "timestamp">'2014-06-11' 
  AND "timestamp"<'2014-11-11'
;

I notice that the row estimates aren’t far of but the cost estimates seem to be a factor 4x larger. This probably isn’t an issue but is there anything I could do about this?

 Aggregate  (cost=214481.45..214481.46 rows=1 width=8) (actual time=51504.814..51504.814 rows=1 loops=1)
   ->  Index Scan using energy_energyentry_prop_id_timestamp_idx on energy_energyentry (cost=0.00..214434.08 rows=18947 width=8) (actual time=136.030..51488.321 rows=13578 loops=1)
         Index Cond: ((prop_id = 82411) AND ("timestamp" > '2014-06-11 00:00:00+00'::timestamp with time zone) AND ("timestamp" < '2014-11-11 00:00:00+00'::timestamp with time zone))
 Total runtime: 51504.841 ms
(4 rows)

Any suggestions might be helpful about how to get this faster, although I’m also fine just hearing I didn’t do anything weird.

EDIT:

My table layout:

                                   Table "public.energy_energyentry"
  Column   |           Type           |                            Modifiers
-----------+--------------------------+-----------------------------------------------------------------
 id        | integer                  | not null default nextval('energy_energyentry_id_seq'::regclass)
 prop_id   | integer                  | not null
 timestamp | timestamp with time zone | not null
 value     | double precision         | not null
Indexes:
    "energy_energyentry_pkey" PRIMARY KEY, btree (id)
    "energy_energyentry_prop_id" btree (prop_id)
    "energy_energyentry_prop_id_timestamp_idx" btree (prop_id, "timestamp")
Foreign-key constraints:
    "energy_energyentry_prop_id_fkey" FOREIGN KEY (prop_id) REFERENCES gateway_peripheralproperty(id) DEFERRABLE INITIALLY DEFERRED

The data ranges from 2012-01-01 till now with new data constantly being added. It’s spreadly uniformly over the “prop” foreign key, with about 2.2k distinct prop’s.


Viewing all articles
Browse latest Browse all 1138

Latest Images

Trending Articles



Latest Images