[Fwd: Réf. : Re: [pgsql-fr-generale] Cluster ...]

-------- Original Message --------
Subject: Réf. : Re: [pgsql-fr-generale] Cluster ...
Date: Tue, 9 Nov 2004 13:47:11 +0100
From: frederic(dot)germaneau(at)bull(dot)net
To: Laurent Mesuré <lmesure(at)nerim(dot)net>

Bonjour,

Pour pouvoir utiliser une architecture telle que tu la proposes il faut que
pg gère le clustering d'instances ( le RAC d'oracle) et à ma connaissance
ça n'est pas le cas.

Une autre solution est peut-être de partionner "logiquement" les tables et
de les mettre dans des bases différentes (et donc si nécessaire dans des
instances voir des serveurs différents)

Exemple:
Une table TABLE1 est découpée en TABLE1_JANVIER, TABLE1_FEVRIER,
TABLE2_FEVRIER...
Et dans les services métiers implémenter le test sur la date d'insertion
...

Par contre il y a une notion avec laquelle je ne suis pas familière et qui
peut être un piste: garder le partionnement logique de tables et utiliser
les dblinks, mais là il y a peut-être un risque de créer un goulot
d'étranglement au niveau de l'instance maître.

Enfin, on s'emballe peut-être: quelle est la taille d'un enregistrement?
pour ma part j'ai fait un TPC-H( test datawarehouse contenant plusieurs
tables dépassant le million d'enregistrements) sur une machine récente et
les performances sont excellentes ( requête la plus longue < 3minutes, (
selects imbriqués avec jointures, ordonnés avec count group by et tout le
tremblement) et ceci juste en tunant finement l'OS et l'instance et surtout
en positonnant correctement des indexes (facteur 100 sur les perfs!).
quelles sont les performances attendues? milliseconde, seconde,minutes,
heures...
quelle est la complexité des requêtes critiques en temps? type ? niveau
d'imbrication, jointures, ordre?

Frédéric