- renvoyer les donneés triées dans l'ordre voulu et s'arrêter une fois une valeur trouvée
- lire toutes les données et conserver la valeur maximum trouvée
La première approche n'est intéressante que si on peut retourner les données triées dans l'ordre voulu, ce qui n'est le cas que pour un index btree.
Utiliser un index brin pour récupérer la valeur max sans lire toutes les données de la table serait théoriquement possible, mais nécessiterait de développer un nouveau mode d'exécution. Comme discuté dans le thread pointé par pifor, le problème est également plus complexe qu'il ne parait car les valeurs min/max stockées dans l'index brin ne sont pas maintenues, et il n'y a aucune garanties que ces valeurs soient toujours visible, ou simplement visible par la requête en cours d'exécution. Cela veut dire la nécessité d'avoir une approche récursive dans le cas où les ranges choisis ne contiennent aucune valeur supposées être présentes uniquement dans ceux-ci. Dans des cas extrêmes le temps d'exécution pourrait devenir bien pire que lire toutes les données séquentiellement (potentiellement avec des workers parallèles). À noter qu'il n'y a pour l'instant aucune statistique qui pourrait aider à décider si ce type de parcours serait intéressant ou non. Le cumul de tout ça explique probablement pourquoi personne n'est intéressé pour travailler sur le sujet.
]]>Bonne après midi
]]>En effet si il y avait des règles ce serait automatisé dans le moteur
Bonne journée
]]>Voici les étapes à suivre pour utiliser cette technique:
1) Créez un nouvel index sur la même colonne que l'index à réindexer. Vous pouvez créer cet index en arrière-plan en ajoutant l'option CONCURRENTLY à la commande CREATE INDEX.
2) Renommez l'ancien index en utilisant une commande ALTER INDEX pour lui donner un nom temporaire. Par exemple, vous pouvez le renommer en "nom_de_l_index_temp".
3) Renommez le nouvel index créé à l'étape 1 en utilisant une commande ALTER INDEX pour lui donner le nom de l'ancien index. Par exemple, vous pouvez le renommer en "nom_de_l_index".
4) Supprimez l'index temporaire créé à l'étape 2.
Cela devrait vous permettre de réindexer vos index sans perturber les transactions en cours.
En ce qui concerne la récupération des transactions avortées lors de la réindexation, il n'y a malheureusement pas de solution fiable à 100%. Vous pouvez utiliser la table pg_stat_activity pour trouver les transactions en cours et essayer de les récupérer en exécutant la même commande après la réindexation. Cependant, certaines transactions peuvent être perdues de cette manière.
]]>Pour certaines couches geo_*_*_p (ponctuel), la géométrie peut être de type multilinestring pour conserver la forme exacte de la symbologie source Autocad. C'est le cas par exemple des arbres qui ont une forme circulaire avec plusieurs arc formant le rendu d'un arbre.
https://zupimages.net/up/23/16/41sy.png
C'est une très mauvaise idée de stocker vos arbres en tant multilinesting pour conserver le dessin de la symbologie Autocad en BD.
Vos outils SIG (QGIS, GEO) sont capables de représenter les objets ponctuels avec une symbologie en fonction de certains attributs.
Il vaut mieux stocker tous les objets ponctuels issus d'Autocad en tant que points ayant, par exemple, comme attributs le nom du bloc et/ou le nom du calque.
Dans QGIS, il suffit ensuite d'utiliser une symbologie basée sur des règles.
]]>L'ajout ou non d'une clé étrangère entre les tables ne change pas ce comportement.
Je déconseille fortement l'utilisation de clés étrangères sur les tables partitionnées PostgreSQL.
D'abord parce qu'un simple ATTACH peut prendre des heures, voire des jours selon la volumétrie et rendre la table inexploitable pendant ce temps (exclusive shared lock).
Ensuite, il y a manifestement des bugs sur les FK de tables partitionnées lors des ATTACH/DETACH(*) qui AMHA ne seront pas résolus de sitôt(**).
Au boulot, en solution de contournement en attendant mieux, on fait une vérification d'intégrité avant de faire le ATTACH ; et on remplace la FK par un trigger "maison" qui fait le check d'intégrité lors des insert/update.
(*) Ref: https://www.postgresql.org/message-id/C … .gmail.com
(**) Ref : https://www.postgresql.org/message-id/C … .gmail.com
J'ai tenté de créer un jeu de données quasiment iso en volumétrie et structure > https://1fichier.com/?bx1vzax1twrsioxsl5fi
Et voici la requête adaptée > https://1fichier.com/?jboe86m6mm69paaszlbv
En parallèle de ça j'ai analysé le résultat via explain DALIBO : https://explain.dalibo.com/plan/13a7h14fb882be93 mais le chemin ne correspond pas au chemin parcouru par la requête avec de "vrais" données. Voici à quoi ressemble le parcours de la requête sur la vraie donnée :
Merci de votre aide.
]]>Si vous parlez français, difficile de vous aider en l'état. Le mieux est de fournir un moyen de reproduire localement de 0, avec la/les requêtes que vous avez déjà, le résultat voulu et/ou les problèmes rencontrés, type plan d'exécution ou autre.
]]>Bonjour @ tous,
Je rencontre quelques problèmes de timeout sur Postgres lors d'insertion et de mises à jour via APIs.
La volumétrie est importante (33 174 requêtes en 15 minutes avec un pic de 4718 requêtes en 1 minute).
Est-il possible de jouer sur quelques paramètres de Postgres pour accepter ces nombreux flux entrants.
En principe on ne change pas des paramètres sans avoir au moins des hypothèses sur la cause des lenteurs, sauf si les paramètres basiques de tuning comme shared_buffers ou work_mem ne sont cohérents avec les capacités du serveur.
Très souvent on installe l'extension pg_stat_statements pour collecter les requêtes normalisées avec leurs temps d'exécution mix/max/moyen, qui donnent des éléments concrets d'analyse.
Une autre méthode très utilisée est de mettre log_min_duration_statement au seuil de durée d'exécution que vous souhaiteriez que vos requêtes ne dépassent pas. Toutes les requêtes plus longues sortiront dans le log. Ensuite on peut analyser le log avec pgBadger.
Il est aussi recommandé d'activer log_lock_waits, qui permettra de savoir si des requêtes sont lentes parce qu'elles attendent des verrous. Les logs produits sont aussi visibles de manière assez claire dans les rapports pgBadger. Pendant qu'on y est on ajoute souvent log_checkpoints et les logs d'autovacuum, ainsi qu'éventuellement log_temp_files.
Il y a aussi des outils de monitoring qui capturent à fréquence régulière la vue pg_stat_activity (entre autres) pour voir combien de connexions sont occupées à faire quoi. Généralement on regarde ces résultats en même temps que les métriques système d'activité CPU et disque.
]]>SHOW autovacuum;
Si cela renvoie "on", c'est activé.
]]>