PostgreSQL La base de donnees la plus sophistiquee au monde.

Forums PostgreSQL.fr

Le forum officiel de la communauté francophone de PostgreSQL

Vous n'êtes pas identifié(e).

#1 Re : Sécurité » CVE-2007-4559 dans pgAdmin4 » Aujourd'hui 04:03:07

Bonjour,


Aucune idée pour ma part, c'est plutôt une question qu'il faudrait poser directement aux développeurs : https://github.com/pgadmin-org/pgadmin4/issues

#2 Re : Général » Incrémentation d'une colonne via un curseur » 21/09/2022 09:52:04

Vous devez utiliser la syntaxe UPDATE ... FROM.  Par exemple:

UPDATE ema.test
SET numligne = rownum
FROM (SELECT pkcol, row_number() OVER () AS rownum) sub
WHERE sub.pkcol = ema.test.pkcol

Pour ma connaissance personnelle, j'aurais besoin de comprendre ce qui bloque dans ma boucle de lecture / mise à jour via curseur et fetch, s'il vous plait ...


Comme l'a indiqué Daniel, au moins le commit est problématique.  Si vous avez corrigé ce point, quelles erreurs avez-vous pour lesquelles la documentation pointée n'apporte pas de réponse ?

#3 Re : Général » Incrémentation d'une colonne via un curseur » 21/09/2022 08:18:20

Merci pour votre réponse, mais je ne comprends pas comment faire un update incrémental d'une colonne sans boucle, avec Oracle, c'est possible via le rownum, mais pas avec PostGreSQL, si?

Vous pouvez utiliser row_number() over () pour obtenir la même chose.

#4 Re : Optimisation » Nombre de requêtes simultanées » 20/09/2022 12:17:11

Oui, cela veut dire que le client a fermé la connexion sans se déconnecter explicitement.  À priori rien n'indique que le problème vienne d'une lenteur côté base de donnée, et à moins que vous ne puissiez montrer un exemple de requête lente ou autre problème côté postgres impossible de vous aider.

#5 Re : Optimisation » Relation VACUUM et REINDEX » 20/09/2022 12:14:57

Aucune idée de ce que fais pgAdmin.  Pour savoir si autovacuum est activé, il suffit d'exécuter la requête suivante :

SHOW autovacuum;

Si cela renvoie "on", c'est activé.

#6 Re : Optimisation » Relation VACUUM et REINDEX » 20/09/2022 10:39:04

Je n'ai pas encore mis en place l'AUTO VACUUM, c'était une question en amont :-)

L'autovacuum est actif par défaut depuis la version 8.3.  Êtes-vous en version 8.2 ou inférieur, ou avez-vous explicitement désactivé l'autovacuum ou vous voulez dire que l'autovacuum est actif, avec les réglages par défaut ?


j'ai 495 000 enregistrements pour un poids total 29 Go soit environ 0,05 Mo / ligne

Ce qui semble donc indiquer une absence de fragmentation hors de controle ?

#7 Re : Optimisation » Nombre de requêtes simultanées » 20/09/2022 05:46:09

Les timeout viennent précisément de ces requêtes parfois trop nombreuses simultanément


Ça ne dis toujours pas d'où ils viennent.  Avez-vous mis en place statement_timeout, ou est-ce côté client ?  Quelle est la valeur du timeout, quelle est la durée de la requête quand cela arrive etc.  Et encore une fois https://wiki.postgresql.org/wiki/Slow_Query_Questions


Etant donné que c'est une API que j'ai mis en place, je ne vois pas les erreurs

Il doit bien y avoir des logs quelque part ?  Et y a-t-il des erreurs côté postgres ?


8gib de mémoire + 1 processeur Intel Xeon Platinum 8175 2vCPUs c'est du 64 bits

Ok, donc un serveur vraiment très peu puissant.

#8 Re : Optimisation » Relation VACUUM et REINDEX » 20/09/2022 05:40:51

Suivez-vous l'activité d'autovacuum sur cette table, notamment pg_stat_user_tables.last_autovacuum et last_autoanalyze?


plusieurs dizaine de milliers d'enregistrements quotidiens


S'agit-il de nouveaux enregistrements ou d'enregistrements modifiés ?  Ce n'est cependant à priori pas grand chose, à moins que chaque ligne fasse plusieurs centaines de Mo.

#9 Re : Optimisation » Relation VACUUM et REINDEX » 19/09/2022 11:25:36

Bonjour,


Par définition autovacuum est le contraire d'une planification manuelle d'un vacuum.


La meilleure chose à faire est normalement de configurer autovacuum pour la ou les tables afin qu'autovacuum la traite avec une fréquence suffisamment importante.  De plus, avez-vous constaté une baisse de performance sur les requêtes utilisant cette table, ou une augmentation significative du bloat et/ou de la volumétrie ?


Pour finir, il n'est généralement pas nécessaire de faire un REINDEX, pour peu que l'autovacuum soit correctement configuré.

#10 Re : Optimisation » Nombre de requêtes simultanées » 19/09/2022 11:20:28

Bonjour,

Un pic à moins de 80 requêtes par seconde ne semble pas spécialement haut.  Impossible de répondre sans plus d'informations cependant.  D'où viennent les timeout exactement ?  Y a-t-il des erreurs remontées par postgres ?  Quels sont les capacités du serveur (RAM, cpu, disque...), et s'agit-il d'un serveur dédié pour postgres ?


Et pour finir, https://wiki.postgresql.org/wiki/Slow_Query_Questions

#11 Re : Général » id exponentielle sur un merge » 15/09/2022 13:56:36

Vous comprenez bien que cette mise à jour se fait en tenant compte des règles d'isolation standard, et vous pouvez donc réinitialiser à une valeur inférieure à ce qui pourrait exister une fois une transaction concurrente committée, ce qui aurait comme conséquence de retourner des valeurs déjà utilisées.  Et dans ce cas, de nombreuses requêtes pourraient échouer, soit immédiatement soit longtemps après, en fonction de l'activité concurrente.

#12 Re : Général » Inner join à string join » 14/09/2022 13:02:06

Ça ne ressemble pas à une erreur postgres, quelle base de données utilisez-vous ?


Il manque la définition de l'aggrégation, mais à priori ce que vous utilisez se plaint pour autre chose.

#13 Re : Général » Inner join à string join » 14/09/2022 11:29:24

Vous devez utiliser une aggrégation, et à priori l'aggrégat string_agg (https://www.postgresql.org/docs/current/functions-aggregate.html ).

#14 Re : Optimisation » Lenteur requête UNION » 08/09/2022 09:56:17

Par exemple, je peux être confronté à des utilisateurs qui veulent afficher une table issue de ma base Postgres avec des centaines de milliers d'enregistrements dans QGIS, le JIT n'intervient pas à ce niveau là si je comprends bien, puisque la requête serait basique mais ce sont plutôt les résultats qui seraient volumineux ?

À priori oui le JIT ne devrait pas se déclencher car un simple "SELECT * FROM table" ne devrait pas être avoir un cout trop élevé, du moins s'il s'agit bien d'une table et non d'une vue complexe.


Quels outils de Postgres-Postgis peuvent m'aider sur ce genre de problématique et réduire les temps de chargement de données volumineuses ?

S'il s'agit de simples "SELECT * FROM table", il n'y a généralement pas grand chose à faire le goulet d'étrangelement étant généralement du côté du réseau voire des disques si les données ne tiennent pas en cache.

#15 Re : C et C++ » Résolu : transactions distribuées - two phase commit » 02/09/2022 10:11:03

EXEC SQL COMMIT PREPARED fonctionne normalement alors que l EXEC SQL EXECUTE IMMEDIATE ouvre une transaction tout seul.

Oui, et comme indiqué dans mon précédent message ce comportement est configurable avec EXEC SQL SET AUTOCOMMIT.  Activez l'autocommit avant d'exécuter un COMMIT PREPARED dynamique et réactivez le après, ou utilisez une connexion dédiée avec l'autocommit toujours activé pour valider ou annuler les transactions préparées.

#16 Re : C et C++ » Résolu : transactions distribuées - two phase commit » 01/09/2022 09:45:06

Bonjour,


Si vous pouvez effectuer un PREPARE TRANSACTION sans avoir explicitement démarré une transaction, c'est que la connexion n'est pas en autocommit (ce qui est le défaut avec ecpg).  Et dans ce cas le COMMIT PREPARED se retrouve également dans une transaction.


Quel est le but de la connexion "one"?  Peut être voulez vous utiliser celle-ci spécifiquement pour valider les transactions, et dans ce cas vous devriez effectuer au préalable un EXEC SQL SET AUTOCOMMIT TO ON sur cette connexion ?  Sinon, il vous faudra changer l'autocommit explicitement à chaque fois.

#17 Re : Optimisation » Lenteur requête UNION » 23/08/2022 11:04:53

J'imagine au moins 10 fois la valeur actuelle, mais comme indiqué il est généralement assez compliqué de le configurer correctement, le cout de la requête n'étant pas vraiment en lien avec le cout du JIT.


Quel type d'applicatif s'agit-il ?  Si c'est purement de l'OLTP à priori le JIT devrait être inutile et vous devriez le désactiver.  Si vous avez un mix OLTP / OLAP vous pouvez l'activer sur une partie des requêtes uniquement, par exemple sur un role en particulier ou une base en particulier.

#18 Re : Optimisation » Lenteur requête UNION » 23/08/2022 10:19:26

Le cout de votre requête est 514424.15, soit plus de 5 fois au dessus de votre limite de 100000.  Malheureusement, le JIT est connu pour causer de genre de problème, le mécanisme de cout actuel (simplement prendre en compte le cout de la requête) n'étant pas entièrement adapté pour quelquechose comme le JIT (dont le cout dépend principalement du nombre de fonctions à compiler).

Autre question, si je veux le désactiver globalement, il me suffit de mettre "jit=off" dans le fichier de conf ?

Oui, puis de recharcher la configuration.

#19 Re : Optimisation » Lenteur requête UNION » 23/08/2022 07:26:48

Apparemment la majorité du temps est passé sur le JIT en version 14:

JIT:
  Functions: 1002
  Options: Inlining true, Optimization true, Expressions true, Deforming true
  Timing: Generation 50.123 ms, Inlining 1032.225 ms, Optimization 2998.037 ms, Emission 2337.827 ms, Total 6418.212 ms


Vous pouvez essayer un "set jit=off;" avant d'effectuer la requête pour confirmer si vous retrouvez les même performances qu'en version 11.  Si c'est le cas, vous pouvez voir pour augmenter les différents couts (cf https://www.postgresql.org/docs/14/jit- … tion.html), voire désactiver jit globalement si vous n'arrivez pas à un comportement acceptable.

#20 Re : Optimisation » Lenteur requête UNION » 20/08/2022 07:18:36

Bonjour,


Avez-vous effectué un VACUUM ANALYZE de la (ou les) bases après le pg_restore ?  Sinon, pouvez-vous donner les plans d'exécution (EXPLAIN (ANALYZE, VERBOSE, BUFFERS) SELECT ...) d'une même requête avec pg 11 et pg14 ?

#21 Re : Général » Creation base avec locale fr_FR.iso885915@euro » 09/08/2022 05:25:22

Bonjour,


D'après https://en.wikipedia.org/wiki/ISO/IEC_8859-15 l'équivalent pour windows serait 28605.  N'utilisant pas windows, difficile d'en dire plus sur le nom final de la collation.

#22 Re : Général » [Résolu] Cumuls de sommes » 09/08/2022 05:23:04

Bonjour,


Les window function sont exactement faites pour ça : https://www.postgresql.org/docs/current … indow.html

Dans votre cas, cumul des valeurs d'années en années, vous pouvez utiliser "sum(m3) OVER (ORDER BY annee)"

#23 Re : Général » Backup-restore d'une table POSTGRES/ POSTGIS » 04/08/2022 04:48:29

En effet.  Mais à priori la commande pg_dump a été effectuée sur le serveur sur lequel vous voulez restaurer (REC?), et non le serveur DEV? (même hostname, même port, même nom de base).

#24 Re : Général » Backup-restore d'une table POSTGRES/ POSTGIS » 03/08/2022 11:14:46

aucun message d'erreur durant la sauvegarde. Tout se déroule nominalement.

Je ne parlais pas forcément d'un message d'erreur, mais peut être un warning prévenant d'une incohérence entre la version du serveur et la version de pg_dump.


Dans le cas d'une mise à jour des instances, quelle serait la marche à suivre?

Il y a plusieurs méthodes pour cela.  La documentation se trouve à https://docs.postgresql.fr/15/upgrading.html

#25 Re : Général » Backup-restore d'une table POSTGRES/ POSTGIS » 03/08/2022 10:10:18

Bonjour,


Avez-vous des messages durant la sauvegarde ?  Apparemment vous utilisez un pg_dump en version 9.5 ou plus mais la base de destination est en version 9.4 ou moins.  Si c'est le cas, vous devriez songer à mettre à jour vos instances vers une version majeure supportée au plus vite.  Si ce n'est pas possible, vos seules alternatives sont d'utiliser un pg_dump de la même version que le serveur de destination, ou d'utiliser un format texte et de supprimer la ligne en question, en espérant qu'aucun autre changement incompatible n'ait eu lieu depuis (ce qui me semble peu probable).

Pied de page des forums

Propulsé par FluxBB