Forums PostgreSQL.fr

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 à 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,

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,

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.

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