Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
J'ai fait différentes simulation sous Postgresql 8.2.4 pour estimer la taille de mes bases de données en fonction du nombre de ligne de chaque table.
J'ai toutefois 2 questions :
- j'obtiens un header d'enregistrement de 32 octets. J'ai vu sur une autres contribution qu'il devrait être de 26 octets (http://forums.postgresql.fr/viewtopic.php?id=1075). Pourquoi cette différence ?
- je n'arrive pas à calculer l'espace disque correcte dans le cas d'un index B-tree. Une marge d'erreur augmente progressivement avec la taille de la table. C'est certainement dû à la hauteur de l'arbre d'index. Quelle formule utiliser pour calculer la hauteur de l'arbre et le nombre d'index pour chaque niveau ?
Merci
Sébastien
Hors ligne
j'obtiens un header d'enregistrement de 32 octets
Comment l'obtenez-vous ? ceci dit, 32 ou 26, la différence n'est pas importante en soi, surtout que la taille de ce header peut changer suivant les versions. Par exemple, sur les anciennes versions de PostgreSQL, un OID était enregistré en plus pour chaque ligne. Cet OID n'est plus enregistré (par défaut). En fait, l'important est de savoir que vous avez un en-tête, pas sa taille.
je n'arrive pas à calculer l'espace disque correcte dans le cas d'un index B-tree
Définissez "correct".
Guillaume.
Hors ligne
J'ai effectué le test suivant : création d'une table et remplissage de 10000 enregistrements.
Schéma de la table du test :
CREATE TABLE aaa_vide
(
champ1 integer,
champ2 integer,
champ3 integer,
champ4 integer,
champ5 integer,
champ6 integer,
champ7 integer,
champ8 integer,
champ9 integer,
champ10 integer
)
WITH (
OIDS=FALSE
);
ALTER TABLE aaa_vide OWNER TO postgres;
Après remplissage de la table, j'obtiens (par la commande "pg_total_relation_size") une moyenne de 113 enregistrements par page de 8192 octets.
Soit 72,49 octets par enregistrement. Si j’ôte 40 octets (10 intégers), j'obtiens un header de 32 octets.
Comment faire pour vérifier que le header possède bien cette taille (autrement que par corrélation) ?
Mon but étant d'estimer l'espace disque nécessaire pour plusieurs centaines de tables contenant chacune plusieurs millions de lignes (un total de plusieurs centaines de Go d'espace disque au total).
Et ce n'est que le début : je n'ai pas encore ajouter les index.
J'ai cherché sur le net et la doc de postgresql, je n'ai rien trouvé pour effectuer des calculs précis.
Hors ligne
Comment faire pour vérifier que le header possède bien cette taille (autrement que par corrélation) ?
Le header est fixe pour une version donnée et en sachant si les OID sont stockées pour chaque ligne ou non. Cela étant dit, vous n'avez pas que le header et les données qui sont enregistrées dans le bloc. Vous avez aussi un page header et des pointeurs vers les tuples (en début de bloc). Le mieux est certainement de regarder les pages 52 et 53 de ce PDF : http://momjian.us/main/writings/pgsql/internalpics.pdf
Mon but étant d'estimer l'espace disque nécessaire pour plusieurs centaines de tables contenant chacune plusieurs millions de lignes
C'est très difficile à faire, notamment parce que vos tables auront forcément un certain taux de fragmentation et qu'il est nécessaire de le prendre en compte.
J'ai cherché sur le net et la doc de postgresql, je n'ai rien trouvé pour effectuer des calculs précis.
Vous ne trouverez rien pour faire des calculs précis. Tout au mieux des estimations mais rien de plus.
Guillaume.
Hors ligne
Question subsidiaire : quel intérêt de calculer cela ?
Guillaume.
Hors ligne
Je vous remercie pour ces précieuses informations.
La base de données est utilisée dans une application dont on ne connait pas à l'origine la taille finale de la base de données (de quelques dizaines de Mo à plusieurs centaines de Go). On effectue des tests par remplissage progressif de la base de données via l'application associée.
Mon but est de faire une estimation de l'espace final en corrélation avec le nombre de lignes et les caractéristiques de chaque table (plusieurs millions d'enregistrement dans chaque table).
J'arrive maintenant à calculer l'espace disque nécessaire pour les tables ne contenant pas d'index.
Je suis rendu au calcul de l'espace disque nécessaire pour les index simples et composés B-tree mais cela ne fonctionne pas encore.
Hors ligne
Pour infos les séquences prennent énormément de place je trouve 
et je pense que vous en aurez une par table à mon avis.
Hors ligne
Pages : 1
