En utilisant PostgreSQL 9.2, j'ai des problèmes avec les requêtes lentes sur une table relativement grande (200+ millions de lignes). Je n'essaye rien de fou, j'ajoute juste des valeurs historiques. Vous trouverez ci-dessous la requête et la sortie du plan de requête.
Ma disposition de table:
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
Les données vont du 01/01/2012 jusqu'à maintenant, avec de nouvelles données constamment ajoutées. Il existe environ 2,2 k valeurs distinctes dans la prop_id
clé étrangère, réparties uniformément.
Je remarque que les estimations de ligne ne sont pas loin, mais les estimations de coût semblent plus grandes d'un facteur 4x. Ce n'est probablement pas un problème, mais est-ce que je pourrais y faire quelque chose?
Je m'attends à ce que l'accès au disque soit le problème, car la table n'est pas en mémoire tout le temps.
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
Des suggestions sur la façon d'accélérer cela?
Je suis également d'accord pour entendre que je n'ai rien fait de bizarre.
prop_time_idx
, mais la définition de la table s'affiche entry_prop_id_timestamp_idx
. Est-ce le même indice? S'il-vous-plaît, réparez.
prop
)? Si seulement un petit pourcentage, un indice ("timestamp", prop)
serait peut-être mieux. Plusieurs index avec les mêmes colonnes de tête ( prop
dans votre cas) sont également souvent redondants.