Re: Volumes importants - lenteur.

Bonjour

J'ai un problème de manipulation des archives de la liste...

j'aurai aimé retrouver tout le fil de cette discussion, histoire de voir si mon problème est équivalent (j'ai 3 000 000 enregistrements dans 1 table de 4 GO, les update sont très lent et le select - avec psql - part dans les choux avec 'mémoire épuisée pour le résultat de la requête" bien que le gestionnaire de tache montre qu'il n'utilise que 1 G0 des 5 G0 de ma machine).

Dans mon cas, je pense qu'il y a des paramètres à changer au niveau du fichier de config... mais je ne sais pas trop lesquel

Merci

MCQ

-----Message d'origine-----
De : pgsql-fr-generale-owner(at)postgresql(dot)org [mailto:pgsql-fr-generale-owner(at)postgresql(dot)org] De la part de Jean-Paul Argudo
Envoyé : mercredi 13 avril 2011 10:20
À : pgsql-fr-generale(at)postgresql(dot)org
Objet : Re: [pgsql-fr-generale] Volumes importants - lenteur.

Bonjour à tous,

Le 12/04/2011 22:29, F. BROUARD / SQLpro a écrit :
> En fait vous êtes un peu aux limites de PG. Le problème de PG c'est
> qu'il ne sait pas multithreader une même requête. C'est son gros point
> noir pour traiter de forts volumes de données, à la différence de Oracle
> ou MS SQL Server qui savent parfaitement multithreader une même requête,
> voir même trop (si il y a 32 processeurs, les requêtes candidates au
> multithreading vont s'exécuter sur les 32 coeurs) et il faut les brider
> en limitant le parallélisme...

PostgreSQL ne peut pas faire de parallélisme tout seul.

En revanche, plusieurs logiciels autour de PostgreSQL savent le faire:

* pgpool-II, via le "Parallel Mode" (libre)
* pl/proxy, dans une certaine mesure (libre)
* GridSQL (libre)
* Greeenplum (propriétaire)
* d'autres? (j'imagine que oui, la liste complètera !)

Des échos que j'ai pu avoir de ci de là, toutes ces technos marchent
très bien, mais ne sont pas vraiment comparables, une étude vous sera
nécessaire pour savoir quel est le meilleur outil pour vous.

> Effectivement si vous pouvez découper votre table en plusieurs petites,
> ce sera déjà un peu quelques chose.

+1 pour tenter le partitioning.

> Ensuite rien ne vous empêche de
> créer une vue agrégeant les tables à l'aide d'un UNION ALL et pour les
> mise à jour passer par des triggers de mise à jour (via les règles).
> http://docs.postgresqlfr.org/8.0/rules-update.html

Burk. Comme l'a dit Cédric, il n'y a pas besoin de faire cela. La table
partitionnée est alors la table "mère", dont héritent toutes les tables
"filles" pour la structure (uniquement, les tables filles peuvent avoir
des index en plus, par exemple, et la table mère pas d'index).

Ainsi, on interroge, insère, modifie ou efface les enregistrement
directement sur la table mère, les triggers (à préférer à la technique
des rules!) se chargeant d'écrire dans la bonne table fille, et le
mécanisme de constraint exclusion se chargeant de lire la(ou les)
tables(s) fille(s) concernée(s) par la requête de lecture...

My 2 cents,

--
Jean-Paul Argudo
www.PostgreSQLFr.org
www.Dalibo.com