Menggunakan PostgreSQL 9.2, saya memiliki masalah dengan pertanyaan lambat pada tabel yang relatif besar (200+ juta baris). Saya tidak mencoba sesuatu yang gila, hanya menambahkan nilai historis. Di bawah ini adalah kueri dan output rencana kueri.
Tata letak meja saya:
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
Data berkisar dari 2012-01-01 hingga sekarang, dengan data baru terus ditambahkan. Ada sekitar 2.2k nilai berbeda di prop_id
kunci asing, didistribusikan secara merata.
Saya perhatikan bahwa perkiraan baris tidak jauh, tetapi perkiraan biaya tampak lebih besar dengan faktor 4x. Ini mungkin bukan masalah, tapi adakah yang bisa saya lakukan?
Saya berharap bahwa akses disk mungkin menjadi masalah, karena tabel tidak ada di memori sepanjang waktu.
EXPLAIN ANALYZE
SELECT SUM("value")
FROM "energy_energyentry"
WHERE
"prop_id"=82411
AND "timestamp">'2014-06-11'
AND "timestamp"<'2014-11-11'
;
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
Adakah saran bagaimana membuat ini lebih cepat?
Saya juga baik-baik saja dengan hanya mendengar saya tidak melakukan sesuatu yang aneh.
prop_time_idx
, namun definisi tabel menunjukkan entry_prop_id_timestamp_idx
. Apakah ini indeks yang sama? Tolong perbaiki.
prop
)? Jika hanya sebagian kecil, mungkin indeks pada ("timestamp", prop)
akan lebih baik. Beberapa indeks dengan kolom utama yang sama ( prop
dalam kasus Anda) juga seringkali berlebihan.