Vous n'êtes pas identifié(e).
Pages : 1
J'utilise http://tatiyants.com/pev/#/plans/new
C'ets le site qui est bugué peut-être ?
Bonjour. Assez régulièrement j'ai un execution time inférieur au slowest node
Ici par exemple temps d'exécution 1,02 seconde alors que le plus lent node prend 1.07 seconde. Je n'ai plus le plan sous la main mais j'ai déjà eu une différence encore plus grande genre 1 seconde de différence.
[
{
"Plan": {
"Node Type": "Aggregate",
"Strategy": "Sorted",
"Partial Mode": "Finalize",
"Parallel Aware": false,
"Async Capable": false,
"Startup Cost": 19615.22,
"Total Cost": 19739.9,
"Plan Rows": 981,
"Plan Width": 45,
"Actual Startup Time": 779.342,
"Actual Total Time": 1009.576,
"Actual Rows": 169016,
"Actual Loops": 1,
"Group Key": [
"a.translation",
"b.translation",
"c.translation",
"document.establishing_date"
],
"Plans": [
{
"Node Type": "Gather Merge",
"Parent Relationship": "Outer",
"Parallel Aware": false,
"Async Capable": false,
"Startup Cost": 19615.22,
"Total Cost": 19719.86,
"Plan Rows": 818,
"Plan Width": 45,
"Actual Startup Time": 779.339,
"Actual Total Time": 936.264,
"Actual Rows": 242644,
"Actual Loops": 1,
"Workers Planned": 2,
"Workers Launched": 2,
"Plans": [
{
"Node Type": "Aggregate",
"Strategy": "Sorted",
"Partial Mode": "Partial",
"Parent Relationship": "Outer",
"Parallel Aware": false,
"Async Capable": false,
"Startup Cost": 18615.2,
"Total Cost": 18625.42,
"Plan Rows": 409,
"Plan Width": 45,
"Actual Startup Time": 699.582,
"Actual Total Time": 766.359,
"Actual Rows": 80881,
"Actual Loops": 3,
"Group Key": [
"a.translation",
"b.translation",
"c.translation",
"document.establishing_date"
],
"Workers": [],
"Plans": [
{
"Node Type": "Sort",
"Parent Relationship": "Outer",
"Parallel Aware": false,
"Async Capable": false,
"Startup Cost": 18615.2,
"Total Cost": 18616.22,
"Plan Rows": 409,
"Plan Width": 41,
"Actual Startup Time": 699.572,
"Actual Total Time": 716.065,
"Actual Rows": 134557,
"Actual Loops": 3,
"Sort Key": [
"a.translation COLLATE \"C\"",
"b.translation COLLATE \"C\"",
"c.translation COLLATE \"C\"",
"document.establishing_date"
],
"Sort Method": "quicksort",
"Sort Space Used": 20263,
"Sort Space Type": "Memory",
"Workers": [
{
"Worker Number": 0,
"Sort Method": "quicksort",
"Sort Space Used": 13859,
"Sort Space Type": "Memory"
},
{
"Worker Number": 1,
"Sort Method": "quicksort",
"Sort Space Used": 13903,
"Sort Space Type": "Memory"
}
],
"Plans": [
{
"Node Type": "Hash Join",
"Parent Relationship": "Outer",
"Parallel Aware": false,
"Async Capable": false,
"Join Type": "Inner",
"Startup Cost": 369.37,
"Total Cost": 18597.45,
"Plan Rows": 409,
"Plan Width": 41,
"Actual Startup Time": 5.025,
"Actual Total Time": 358.178,
"Actual Rows": 134557,
"Actual Loops": 3,
"Inner Unique": false,
"Hash Cond": "(document.redaction_place_code = (b.val)::integer)",
"Workers": [],
"Plans": [
{
"Node Type": "Hash Join",
"Parent Relationship": "Outer",
"Parallel Aware": false,
"Async Capable": false,
"Join Type": "Inner",
"Startup Cost": 221.84,
"Total Cost": 18337.94,
"Plan Rows": 97,
"Plan Width": 34,
"Actual Startup Time": 1.526,
"Actual Total Time": 260.962,
"Actual Rows": 134557,
"Actual Loops": 3,
"Inner Unique": false,
"Hash Cond": "(\"left\"(document.basis, 1) = c.val)",
"Workers": [],
"Plans": [
{
"Node Type": "Hash Join",
"Parent Relationship": "Outer",
"Parallel Aware": false,
"Async Capable": false,
"Join Type": "Inner",
"Startup Cost": 111.08,
"Total Cost": 17409.83,
"Plan Rows": 13062,
"Plan Width": 25,
"Actual Startup Time": 0.754,
"Actual Total Time": 199.868,
"Actual Rows": 134557,
"Actual Loops": 3,
"Inner Unique": false,
"Hash Cond": "(document.doc_type = (a.val)::smallint)",
"Workers": [],
"Plans": [
{
"Node Type": "Index Scan",
"Parent Relationship": "Outer",
"Parallel Aware": true,
"Async Capable": false,
"Scan Direction": "Forward",
"Index Name": "idx_doc_docst",
"Relation Name": "document",
"Alias": "document",
"Startup Cost": 0.42,
"Total Cost": 15535.84,
"Plan Rows": 163271,
"Plan Width": 16,
"Actual Startup Time": 0.033,
"Actual Total Time": 129.7,
"Actual Rows": 134557,
"Actual Loops": 3,
"Filter": "((establishing_date <= '2021-01-01'::date) AND (establishing_date >= '2020-01-01'::date))",
"Rows Removed by Filter": 154106,
"Workers": []
},
{
"Node Type": "Hash",
"Parent Relationship": "Inner",
"Parallel Aware": false,
"Async Capable": false,
"Startup Cost": 110.46,
"Total Cost": 110.46,
"Plan Rows": 16,
"Plan Width": 16,
"Actual Startup Time": 0.685,
"Actual Total Time": 0.686,
"Actual Rows": 16,
"Actual Loops": 3,
"Hash Buckets": 1024,
"Original Hash Buckets": 1024,
"Hash Batches": 1,
"Original Hash Batches": 1,
"Peak Memory Usage": 9,
"Workers": [],
"Plans": [
{
"Node Type": "Seq Scan",
"Parent Relationship": "Outer",
"Parallel Aware": false,
"Async Capable": false,
"Relation Name": "label2",
"Alias": "a",
"Startup Cost": 0,
"Total Cost": 110.46,
"Plan Rows": 16,
"Plan Width": 16,
"Actual Startup Time": 0.659,
"Actual Total Time": 0.664,
"Actual Rows": 16,
"Actual Loops": 3,
"Filter": "((lang = 1) AND (type = 23))",
"Rows Removed by Filter": 6748,
"Workers": []
}
]
}
]
},
{
"Node Type": "Hash",
"Parent Relationship": "Inner",
"Parallel Aware": false,
"Async Capable": false,
"Startup Cost": 110.46,
"Total Cost": 110.46,
"Plan Rows": 24,
"Plan Width": 16,
"Actual Startup Time": 0.716,
"Actual Total Time": 0.717,
"Actual Rows": 24,
"Actual Loops": 3,
"Hash Buckets": 1024,
"Original Hash Buckets": 1024,
"Hash Batches": 1,
"Original Hash Batches": 1,
"Peak Memory Usage": 10,
"Workers": [],
"Plans": [
{
"Node Type": "Seq Scan",
"Parent Relationship": "Outer",
"Parallel Aware": false,
"Async Capable": false,
"Relation Name": "label2",
"Alias": "c",
"Startup Cost": 0,
"Total Cost": 110.46,
"Plan Rows": 24,
"Plan Width": 16,
"Actual Startup Time": 0.017,
"Actual Total Time": 0.703,
"Actual Rows": 24,
"Actual Loops": 3,
"Filter": "((lang = 1) AND (type = 4))",
"Rows Removed by Filter": 6740,
"Workers": []
}
]
}
]
},
{
"Node Type": "Hash",
"Parent Relationship": "Inner",
"Parallel Aware": false,
"Async Capable": false,
"Startup Cost": 110.46,
"Total Cost": 110.46,
"Plan Rows": 2965,
"Plan Width": 16,
"Actual Startup Time": 3.45,
"Actual Total Time": 3.45,
"Actual Rows": 2965,
"Actual Loops": 3,
"Hash Buckets": 4096,
"Original Hash Buckets": 4096,
"Hash Batches": 1,
"Original Hash Batches": 1,
"Peak Memory Usage": 173,
"Workers": [],
"Plans": [
{
"Node Type": "Seq Scan",
"Parent Relationship": "Outer",
"Parallel Aware": false,
"Async Capable": false,
"Relation Name": "label2",
"Alias": "b",
"Startup Cost": 0,
"Total Cost": 110.46,
"Plan Rows": 2965,
"Plan Width": 16,
"Actual Startup Time": 0.35,
"Actual Total Time": 1.567,
"Actual Rows": 2965,
"Actual Loops": 3,
"Filter": "((lang = 1) AND (type = 16))",
"Rows Removed by Filter": 3799,
"Workers": []
}
]
}
]
}
]
}
]
}
]
}
]
},
"Planning Time": 1.011,
"Triggers": [],
"Execution Time": 1015.308
}
]
Savez-vous ce qui se passe ? Ma query dure combien de temps alors en réalité ?
J'ai un certain nombre de queries qui retournent comme résultat un gros string (100k jusqu'à 4 mégas à l'extrême) qui contient en fait un csv (le client ne peut consommer que du CSV).
Lorsque j'ai le string en résultat de la query je le compresse avec une méthode en java et je le retourne au client. Ca marche.
Je me demande juste s'il était possible d'obtenir un csv à postgre directement compressé (dans un format portable) ?
En java, en code simplifié, j'ai ça :
CopyManager copyManager = ...
copyManager.copyIn("COPY ...ici mon sql... FROM STDIN DELIMITER ';' CSV HEADER"...);
En ligne de commande je peux le faire ainsi compressé : COPY foo_table to PROGRAM 'gzip > /tmp/foo_table.csv' delimiters',' CSV HEADER;
Mais comment le faire programatiquement (en java ou autre)?
Bonjour ced. Je fais face exactement au même problème que vous et j'ai aussi voulu essayer de créér des statistiques. Le problème c'est qu'on ne peut créér des stats que sur une seule table. Moi mon problème vient d'un lien entre 2 tables. Auriez-vous une suggestion ?
Je trouve complètement incompréhensible que postgre produise l'information comme quoi le plan est catastrophique mais continue systématiquement à le répéter au lieu d'avoir un mécanisme interne d'amélioration.
Bonjour les amis. Je fais face à un problème très connu sur le net visiblement.
Postgre construit un mauvais plan qui résulte en un nested loop et un index scan exécutés 3000x. Le plan croit qu'il y aura 1 row mais il y en a 3000. Malgré le fait que j'exécute le sql des dizaines de fois postgre continue à produire le même mauvais plan complètement déconnecté de la réalité. C'est vraiment étonnant que postgre dispose de l'info que le plan est mauvais mais continue à reproduire le même problème indéfiniment.
Bref j'ai appliqué de nombreuses solutions trouvées sur le net mais sans succès (le vacuum est ok, les stats contiennent le bon nombre de rows, et tout un tas d'autres checks usuels sont ok).
Au final le plus simple c'est de faire un "SET enable_nestloop = off;" avant d'exécuter mon sql. Je peux vivre avec ça mais je voudrais être sur que ce "SET enable_nestloop = off;" ne soit effectif que sur mon sql lent et pas sur les éventuels autres qui seraient en cours d'exécution en même temps.
Comment puis-je dire à postgre de n'appliquer "SET enable_nestloop = off;" que sur 1 seul sql ?
Autre chose: est-ce qu'il est prévu dans la roadmap que postgre utilise son "explain analyze" pour s'améliorer plutôt que de répéter systématiquement la même erreur sans aucun mécanisme interne pour corriger un tel disfonctionnement ?
Merci !
Pages : 1
