Vous n'êtes pas identifié(e).
La différence se trouve au niveau du contenu des colonnes, plus précisément l'une des colonnes à SELECT contient plusieurs caractères , une immense length, se qui ralenti le temps d’exécution du SELECT
Bonjour,
J'ai un PG 9.6 hébergé dans une VM linux. Je fais une simple requête SELECT x, y, z FROM table WHERE status = 'KO'. Sur pgAdmin, en regardant EXPLAIN(ANALYZE), le temps d’exécution fait dans les 100ms (planning time < 1ms), par contre lorsque je lance la requête sans EXPLAIN, la requête met plus de temps que prévu, voir 332 487ms. Le résultat de requête ne fait que 753 lignes en passant.
Qu'est ce qui peut expliquer ce décalage énorme de temps d’exécution, EXPLAIN ANALYZE n'est il pas sensé refléter l’exécution réelle ?
Merci d'avance de votre intérêt pour le sujet
Ok merci beaucoup pour ces informations
Merci,
Et si la table à attacher possède des index, celles si resteront donc toujours comme index de la nouvelle partition de la table cible et ne seront pas recréé au moment de l'ATTACH ?
Bonjour,
Nous avons une assez large table avec à peu près 2millins d'enregistrement. Nous voulons exécuter la commande suivante: ALTER TABLE la_table ATTACH PARTITION new_table FOR VALUES IN (NULL);
Cette commande met environ 8h à s'executer, il y aurait il moyen d'améliorer ce temps de traitement ? Entre autre, connaitriez vous quel paramètre entre en jeu lors de l'execution de cette commande ? (shared_buffer ? work_mem ? maintenance_work_mem ?)
Par ailleurs, à peu près la même question pour une commande copy => çà joue avec shared_buffer ou work_mem ?
Merci déjà de l'attention que vous porteriez sur le sujet.
Cordialement,
Bonjour,
Excusez pour la réponse tardive.
Oui, effectivement c'est une table partitionnée en plusieurs partitions , çà peut bien être çà.
Merci
Bonjour à tous,
Nous travaillons sur un PG13 environnement linux : CPU 6 et RAM = 14GB.
Nous avons une table de 37GB (19GB de data et 18GB d'index) environ comportant 138544894 nombre de lignes.
Lorsqu'on fait une copie de cette table vers une autre table que ce soit avec INSERT INTO SELECT * FROM la_table ou la commande COPY FROM fichier-contenant_les_donnees_de_la_table, PG tombe sur un out of memory Failed on request of size 1048576 in memory context "AfterTriggerEvents".
Il n'y a pas d'autres requêtes en cours sur la base à part la copie, comment donc expliquer cette erreur svp et comment la contourner sinon ?
Merci d'avance de votre intérêt sur le sujet
Cdlt,
Ok, en tout cas l'erreur semble disparaitre avec cette action.
Merci de votre aide
Cordialement,
Merci de vos réponses,
Sébastien, oui que se soit un simple ANALYZE ou un VACUUM ANALYZE çà a renvoyé le out of memory.
Guillaume, effectivement il y en a de stats MCV de créés, vous pensiez que çà serait dù à cela ? En tout cas j'en ai supprimé une récente et maintenant l'ANALYZE passe, seulement je ne comprends toujours pas pourquoi çà consommerait tant de mémoire et pourquoi sur cette table en particulière ?
Merci de l'attention que vous portiez à ce sujet.
Merci,
Le log PG montre :
LOG: could not fork new process for connection: Cannot allocate memory (défois il n' y a pas cette trace)
ERROR: out of memory
DETAIL: Failed on request of size 118275 in memory context "BuildRelationExtStatistics".
STATEMENT: VACUUM ANALYZE
le journalctl ne montre rien
Ce qui m'étonne aussi c'est que lorsqu'il fait un ANALYZE d'une autre table plus grande , qui elle fait 48GB avec 50 694 444 nb de lignes, çà passe.
Bonjour à tous,
On utilise PG 14 sur debian.
Dans la base existe une table de 34GB avec 4 653 064 nb de lignes.
Avant lorsqu'on lançait un ANALYZE sur cette table, l'opération aboutie; mais maintenant lorsqu'on lance l'ANALYZE çà renvoie après un certain temps d'execution :
ERROR: out of memory
DETAIL: Failed on request of size 27336 in memory context "BuildRelationExtStatistics".
Je tiens à remarquer que le nombre de lignes de cette table depuis le dernier ANALYZE successful n'a pas beaucoup grandit. Et un repack est planifié chaque week-end pour éviter la fragmentation de la table et de l'index.
L'erreur se produit aussi meme si il y a presque seul ANALYZE, la requête qui se lance dans le sgbd.
=> Pouvez vous indiquer svp, ce qui peut donc être la cause de cette erreur et si existe une autre solution que d'augmenter la RAM ?
Merci d'avance
Bonjour,
Merci pour votre réponse.
Ok je vais voir cela.
Cordialement,
Bonjour,
Notre BDD est actuellement hébergée dans un environnement centOS PG9.6, et nous voulons la migrer vers une autre VM Debian avec une montée de version vers la PG13 avec.
J'aimerai savoir s'il y aurait un moyen de faire çà à chaud (un dump/restore de la BDD met dans les 24h pour finaliser), peut être en jouant avec les WAL ?
Si quelqu'un a une idée du procédé svp ?
Merci d'avance.
Merci pour les conseils.
Pour les CPU, d'après les constats, le load average n'est pas si haut que çà (inférieur au nombre de CPU) surtout lorsque ce phénomène se produit, le load dimunue même.
Bonjour,
Quel environnement ?
- Vérifier si le service PG est démarré
- Vérifier si l'hôte est pingable
- Vérifier que listen_address est bien paramétré dans le fichier postgresql.conf, (mettre listen_address='*' par exemple)
- Vérifier le fichier pg_hba.conf quand même, voir si il faut paramètrer l'accès à l'hôte
- Vérifier si le port est ouvert et non bloqué par un parfeu par exemple
En général, cela tourne autour de ces critères.
Bon courage
Bonjour,
Je ne sais pas si votre sujet est toujours d'actualité mais à mon avis, vous pourriez avoir cela avec dblink : https://docs.postgresql.fr/10/contrib-d … ction.html
Bonjour,
Nous sommes sur un environnement linux centOS avec pg12 d'y installer. Aujourd'hui j'ai remarqué en faisant un htop que plusieurs des requêtes postgres tombent dans un status BIND, vous savez lorsque vous faites un htop pour voir les requêtes en cours et normalement à la fin il y a des "SELECT" ou "idle", cela dépend, et là je dirais que 90% des requêtes sont BIND. Déjà que veut dire ce statut BIND ? C'est pas toujours qu'on voit çà mais c'est plutôt qu'on c'est lent au niveau exécution des requêtes, je soubconne des contentions de locks car en faisant pg_stat_activity on voit que la plupart des requêtes, elles sont en wait_event = lock manager et wait_event_type = LWlock, et une accumulation de requête se fait sentir également suite à cela, après un certain temps çà part bien sur, mais la question est que veut dire exactement wait_event = lock manager et wait_event_type = LWlock ? Quelle en est la cause ? Et comment ou quoi faire si la situation se reproduit et/ou pour que la situation de ce genre ne se reproduise plus ?
Auriez vous une, des idées sur le sujet svp ?
Merci d'avance
Ok merci pour les réponses
Ok, donc la config à adopter serait de faire work_mem ~ (RAM - Shared_buffers - maintenance_ work_mem) / max_connections ?
Et si on configure work_mem a une valeur trop élevée çà va entrainer quoi, une erreur "out of memory" ?
Bonjour,
J'aimerai savoir comment affiner le paramètrage de work_mem sur postgresql.
Exemple si on prend un evironnement linux , avec pg9.6 et ram = 10G, disons avec une configuration de shared_buffers = 3G (environ 25% de la RAM) et max_connection = 50,
est ce que cela veut il dire que sur les 10G de la RAM 3 G sera allouée spécialement pour les caches pg et donc on aurait 7G restant pour work_mem, maintenance_work_mem et les caches pour fsync ? Supposons que le nombre maximum de jointure dans une requête est de 4 + possibilité de trie sur les requêtes, et qu'à un instant T on aurait en moyenne 30 requêtes en parallèle, et en plus on va paramétrer maintenance_work_mem = 1G; est ce que de par ce fait la valeur max à attribuer à work_mem serait donc dans cette situation de : work_mem = 50 MB sachant que 50MB * 4 (jointure) * 30 (connexions en mm temps) = 6000MB = 5.86GB retirés dans la RAM ?
Merci pour vos réponses
Bonjour,
Avec un environnement linux PG 9.6, j'imagine que le partitionnement de la table se fait avec le principe d'héritage ?
Considérons alors que j'ai une table volumineuse qui n'est pas encore partitionnée car l'architecture de départ n'a pas prévue cela. Maintenant, vu que la taille de la table dépasse celle de la RAM, j'aimerai tester un partitionnement, ma question est donc: lorsque je vai créer les tables de partitions , existe t il un moyen de transférer les données depuis la table mère vers les nouvelles partitions créées ou devrai je faire çà de façon manuelle ?
Merci pour votre attention
duple a écrit :Salut,
Si çà peut aider, existe un logiciel "Navicat" qui permet de se connecter sur plusieurs SGBD, tel que Oracle, PG, Mysql, ... et on peut exécuter des requêtes dedans, on peut également exporter les données sous plusieurs format : le xml y compris. Tu peux même paramétrer çà pour que çà se lance en tache planifiée, super le soft nonMerci mais j'ai une préférence pour le GNU.
Ton PG est hébergé dans un environnement Linux, mais tu peux bien aussi avoir un poste client windows dont navicat installé. Sinon, il me semble que Navicat fonctionne sous les environnements Mac, Windows et Linux.
Ah je me suis trompé, en revérifiant il avait bien des INSERT INTO RETURNING INTO STRICT dans mon code. J'ai renforcé les conditions (verification de données ) pour entrer dans cette partie de "INSERT INTO" et c'est bon.
Les pistes de rjuju et gleu : clause INTO STRICT et le numéro de ligne où l'eurreur est rencontré m'ont aidé.
Merci à tous.
duple a écrit :Sinon, est ce que quelqu'un connait quelles sont les actions qui peuvent engendrer l'erreur ERROR: query returned no rows ?
À priori une clause INTO STRICT dans une commande plpgsql.
>>> A j'ai que INTO dans mes requêtes mais pas STRICT