Forums PostgreSQL.fr

JeremyM

Membre

Requête lente sur une table partionné.

Bonjour,

J'ai la problématique suivante:
Le requête suivante select max(clock) from history_uint where itemid=xxxx AND clock <= xxxxxx est très lente.
Après vérification du plan d'exécution, il s'avère que le planificateur passe dans toutes les tables filles de history_uint.

J'utilise PostgreSQL 9.0.4.
La structure de la table est la suivante :

                        Table "public.history_uint"
 Column |     Type      |          Modifiers          | Storage | Description 
--------+---------------+-----------------------------+---------+-------------
 itemid | bigint        | not null                    | plain   | 
 clock  | integer       | not null default 0          | plain   | 
 value  | numeric(20,0) | not null default 0::numeric | main    | 
 ns     | integer       | not null default 0          | plain   | 
Indexes:
    "history_uint_1_tmp" btree (itemid, clock)
Triggers:
    insert_history_uint_trigger BEFORE INSERT ON history_uint FOR EACH ROW EXECUTE PROCEDURE history_uint_insert_trigger()
Child tables: history_uint_y2013m08d15,
              history_uint_y2014m10d11,
              history_uint_y2014m10d12,
              history_uint_y2014m10d13,
              history_uint_y2014m10d14,
              history_uint_y2014m10d15,
              history_uint_y2014m10d16,
              history_uint_y2014m10d17,
              history_uint_y2014m10d18,
              history_uint_y2014m10d19,
              history_uint_y2014m10d20,
              history_uint_y2014m10d21,
              history_uint_y2014m10d22,
              history_uint_y2014m10d23,
              history_uint_y2014m10d24,
              history_uint_y2014m10d25,
              history_uint_y2014m10d26,
              history_uint_y2014m10d27,
              history_uint_y2014m10d28,
              history_uint_y2014m10d29,
              history_uint_y2014m10d30,
              history_uint_y2014m10d31,
              history_uint_y2014m11d01,
              history_uint_y2014m11d02,
              history_uint_y2014m11d03,
              history_uint_y2014m11d04,
              history_uint_y2014m11d05,
              history_uint_y2014m11d06,
              history_uint_y2014m11d07,
              history_uint_y2014m11d08,
              history_uint_y2014m11d09,
              history_uint_y2014m11d10,
              history_uint_y2014m11d11,
              history_uint_y2014m11d12,
              history_uint_y2014m11d13,
              history_uint_y2014m11d14,
              history_uint_y2014m11d15,
              history_uint_y2014m11d16,
              history_uint_y2014m11d17,
              history_uint_y2014m11d18,
              history_uint_y2014m11d19,
              history_uint_y2014m11d20,
              history_uint_y2014m11d21,
              history_uint_y2014m11d22,
              history_uint_y2014m11d23,
              history_uint_y2014m11d24,
              history_uint_y2014m11d25,
              history_uint_y2014m11d26,
              history_uint_y2014m11d27,
              history_uint_y2014m12d28,
              history_uint_y2014m12d29,
              history_uint_y2014m12d30,
              history_uint_y2014m12d31,
              history_uint_y2015m01d01,
              history_uint_y2015m01d02,
              history_uint_y2015m01d03,
              history_uint_y2015m01d04,
              history_uint_y2015m01d05,
              history_uint_y2015m01d06,
              history_uint_y2015m01d07,
              history_uint_y2015m01d08,
              history_uint_y2015m01d09,
              history_uint_y2015m01d10
Has OIDs: yes

Chacune des table contient environ 12 000 000 de lignes, et il y a une rotation sur 4 mois.
Un explain de la requête est disponible ici : http://explain.depesz.com/s/UCgi

Voici la structure des tables history_uint_yxxxxmxxdxx

                   Table "public.history_uint_y2015m01d10"
 Column |     Type      |          Modifiers          | Storage | Description 
--------+---------------+-----------------------------+---------+-------------
 itemid | bigint        | not null                    | plain   | 
 clock  | integer       | not null default 0          | plain   | 
 value  | numeric(20,0) | not null default 0::numeric | main    | 
 ns     | integer       | not null default 0          | plain   | 
Indexes:
    "history_uint_y2015m01d10_1" btree (itemid, clock)
Check constraints:
    "history_uint_y2015m01d10_clock_check" CHECK (clock >= 1420848000 AND clock < 1420934400)
Inherits: history_uint
Has OIDs: yes

Là j'avoue que je sèche totalement et toute aide serai la bienvenue.

Merci.

gleu

Administrateur

Re : Requête lente sur une table partionné.

Sur l'EXPLAIN, je ne vois que les tables de octobre 2014 à janvier 2015. Or sur la définition de la table, on voit des partitions à partir de 2013. Donc il ne les parcourt pas toutes.

---

Guillaume.

JeremyM

Membre

Re : Requête lente sur une table partionné.

Bonjour,

Merci pour ce retour. En fait il reste une seule table de 2013 qui n'a pas correctement été supprimée. Sinon dans le explain, il passe bien dans les table de history_uint_y2014m10d11 à history_uint_y2015m01d05.

Pour le coup en me relisant je viens de comprendre pourquoi il passe dans autant de tables :

La condition de recherche est sur clock <= XXXXXX. Donc il teste toutes les entrées dans toutes les tables où clock est inférieur à XXXXX.

Chaque table contient en moyenne 12 000 000 de lignes. Pour le coup je ne vois pas comment réduire le temps d'exécution de la requête. Actuellement elle prend environ 22 s et 5minutes en fonction de la charge du serveur.

Jérémy.

gleu

Administrateur

Re : Requête lente sur une table partionné.

Ça fait du 500000 lignes par seconde dans le meilleur des cas. En effet, je vois difficilement comment faire mieux.

---

Guillaume.