[gull] MySQL table partitions

[Daniel Cordey]

On Friday 24 November 2006 09:57, Marc SCHAEFER wrote:

> http://www.postgresql.org/docs/8.1/interactive/ddl-partitioning.html
>
>    On utilise ici l'héritage (PostgreSQL est vaguement OO).

OK, c'est bien ca. Le 'hash partitioning' n-est pas supporte mais les 
fonctionalites sont presques les memes a quelques details prets.

> à quoi servent les tables MERGE?  sont-ce simplement des VIEW actives ?

Je ne connais pas les VIEW, mais une table MERGE est le regroupement de N 
tables sementiquement identiques, permettant de faire un SELECT global sur 
l'ensemble des tables "groupees" dans la table MERGE. Cela evite simplement 
l'emploi des JOIN. Les update/insert doivent continuer a se faire sur les 
tables initiales car la table MERGE n'a pas d'indexes et se repose sur celles 
des tables "grtoupees".

> PS/2: jamais utilisé cela. Lorsque j'arrive à de tels besoins en
>       performance, je passe par dbm.

:-) Si je n'avais qu'une seule clef se serait ideal. Ce n'est helas de loin 
pas le cas. De plus, il me semble que dbm n'est pas performant lors de 
l'adjonction de nouveaux elements. Si mes souvenirs sont bons, dbm ne doit-il 
pas re-evaluer son hash-domain a chaque insertion ?

Les partitions me semblent un super comproms en offrant exactement ce dont 
j'ai besoin. A savor, simplicite de la gestion de la table (par opposition a 
mes 30 tables dans MERGE), simplicite d'acces en INSERT/UPDATE et performance 
optimums.

Le probleme est que je ne sais pas comment le systeme va reagir avec 30 ou 40 
partitions et 12 subpartitions dans chaque partition. Ca fait quand meme 
>1080 fichiers d'ouverts... (en plus de tous les autres) pour le DB serveur. 
Raison pour laquelle je cherche quelqu'un ayant un peu d'experience dans ce 
domaine.

dc