Vous n'êtes pas identifié(e).
rsyslog=> ALTER TABLE systemevents ALTER fromhost SET STATISTICS 1000;
ALTER TABLE
rsyslog=> ANALYZE systemevents;
ANALYZE
rsyslog=> EXPLAIN ANALYZE SELECT * FROM systemevents WHERE fromhost = 'XXXX' ORDER BY id desc LIMIT 20 ;
QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=26482.21..26482.26 rows=20 width=952) (actual time=8417.810..8417.831 rows=20 loops=1)
-> Sort (cost=26482.21..26499.58 rows=6949 width=952) (actual time=8417.806..8417.813 rows=20 loops=1)
Sort Key: id
Sort Method: top-N heapsort Memory: 30kB
-> Index Scan using nomequipement on systemevents (cost=0.00..26297.30 rows=6949 width=952) (actual time=0.184..8412.708 rows=2686 loops=1)
Index Cond: ((fromhost)::text = 'XXXX'::text)
Total runtime: 8419.195 ms
(7 rows)Les résultat sont bien plus intéressant, une requêtes sur cette base est beaucoup plus rapide
maintenant une question de fonctionnalité à quel moment la commande ANALYSE est-elle lancé automatiquement ? si elle est lancé.
Même question pour le VACUUM, est-ce qu'il faut le lancer manuellement ou elle se lance automatiquement de temps en temps ?.
Dans tous les cas Merci beaucoup pour tous les debug.
Il semblerais que les requêtes soient beaucoup plus rapide, après je sais pas si c'est le changement du temps d'analyse des stats pour en améliorer l'effet (si j'ai bien compris) ou du au faite que j'ai grandement réduit la base (40% en moins).
Surement que les deux on du jouer.
Merci encore
Cordialement
Dragondark De Lonlindil
Hors ligne
VACUUM et ANALYZE sont par défaut exécutés automatiquement quand les tables en ont besoin (suivant la configuration évidemment) grâce à l'autovacuum. Il est tout à fait possible qu'ils ne soient pas exécutés si la configuration n'est pas adéquate.
Quant à l'améloration de durée d'exécution, il est clair que si vous faites plusieurs changements en même temps, il est impossible de savoir lequel a permis de gagner réellement. Si vous supprimez pratiquement 50% de la volumétrie de la base, comparez les deux durées d'exécution n'a pas de sens.
Guillaume.
Hors ligne
Je ne pense pas que cela soit que la volumétrie qui ai impacter sur la durée de la requete à ce point. actuellement je suis à 46M de logs pour 60M hier (apres-midi) (16h)
ce qui est certains c'est que l'analyse y est pour beaucoup, les requêtes simples (1filtre) sont beaucoup plus rapides, le problème c'est que quand je dis beaucoup plus rapide c'est -30s
ce qui n'est toujours pas suffisant pour l'utilisation qu'on souhaitent en faire.
j'avais commencer à spliter les données car je pensais que ce que j'aurais gagner en performance ne serrait pas suffisant (20/30% de gain)
Et l'avantage c'est que cela me permet en même temps de trier mes données.
Je vais me renseigner sur l'autovacuum, en tous cas merci pour ton aide.
Bonne journée
Hors ligne
Il est possible d'augmenter encore la valeur du STATISTICS; Pas sûr que ça aura un grand impact. Mais bon, à essayer.
Guillaume.
Hors ligne