Re: 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