Re: [pgsql-fr-generale] pg_freespacem ap et théorie sur le free space map

[Guillaume Lelarge <guillaume(at)lelarge(dot)info>]

DANTE Alexandra a ecrit le 17/01/2007 14:31:
> Existe-t-il une doc dans laquelle les calculs faits pour déterminer les 
> champs "avgrequest", "interestingpages", et "storedpage" utilisés pour 
> définir le free space map sont détaillés ?

A part les sources, je n'en connais pas.

avgrequest est la taille moyenne des requêtes d'espaces libres. Dis 
autrement, quand le serveur a besoin de stocker des données dans une 
table, il va exécuter la fonction GetPageWithFreeSpace 
(src/backend/storage/freespace/freespace.c) en lui précisant la relation 
et l'espace requis. D'après ce que je viens de lire, seule la fonction 
RelationGetBufferForTuple (backend/access/heap/hio.c) l'appelle en lui 
précisant la taille des données augmentée du paramètrage du FILLFACTOR 
pour cette table. Par défaut, avgrequest vaut BLCKSZ / 32 (soit 256 si 
vous ne l'avez pas modifié).

Dans votre cas, cela semble indiquer que les différentes insertions que 
vous avez effectuées ont lancés des demandes pour un espace libre d'une 
moyenne de 250 octets.

Une page intéressante (interestingPages) est une page dont l'espace 
libre dépasse avgrequest. Autrement dit, toujours dans votre cas, une 
page sur les trois de votre table doit avoir plus de 250 octets de 
libre. (Plus d'infos avec la fonction vac_update_fsm de 
backend/commands/vacuum.c et avec la fonction RecordRelationFreeSpace de 
src/backend/storage/freespace/freespace.c (à savoir que cette dernière 
est utilisée par le VACUUM pour rapporter les espaces libres dans la 
table au FSM). D'après ce que vous dîtes (que des insertions, pas de 
suppressions), je parierais pour la dernière qui ne doit pas être pleine.

Je suppose que storedPages est le nombre de pages tracées pour cette 
table dans le FSM, mais j'avoue que c'est un peu plus flou pour moi. 
Apparement, dans le cas de vac_update_fsm, c'est exactement la même 
valeur que interestingPages.

Pour vérifier mes dires, le mieux est d'utiliser la contrib 
pg_freespacemap car elle vous permet d'avoir plus d'infos. Notamment 
pg_freespacemap_pages vous permet de connaître le nombre d'octets libres 
pour une page particulière. Essayez par exemple ceci :
SELECT c.relname, p.relblocknumber, p.bytes
             FROM pg_freespacemap_pages p INNER JOIN pg_class c
             ON c.relfilenode = p.relfilenode INNER JOIN pg_database d
             ON (p.reldatabase = d.oid AND d.datname = current_database())
             WHERE c.relname='district';

(Requête extraite du README de pg_freespacemap.)

> [...]
> J'ai ensuite lancé un VACUUM VERBOSE sur cette table et j'ai obtenu :
> base=# vacuum verbose district;
> INFO:  vacuuming "public.district"
> INFO:  index "pk_district" now contains 100 row versions in 2 pages
> DETAIL:  0 index row versions were removed.
> 0 index pages have been deleted, 0 are currently reusable.
> CPU 0.00s/0.00u sec elapsed 0.00 sec.
> INFO:  "district": found 0 removable, 100 nonremovable row versions in 3 
> pages
> DETAIL:  0 dead row versions cannot be removed yet.
> There were 0 unused item pointers.
> 1 pages contain useful free space.
> 0 pages are entirely empty.
> CPU 0.00s/0.00u sec elapsed 0.00 sec.
> VACUUM
>
> De même, comment expliquer le commentaire "1 pages contain useful free 
> space" ?

1 page contient assez d'espace pour être utilisable facilement pour y 
stocker d'autres données (étant donné que la place libre de cette page 
dépasse la moyenne des requêtes pour le stockage de données).

Je ne suis pas sûr d'être très clair, je ne suis pas non plus sûr 
d'avoir exactement tout compris dans les sources mais c'est ce qui me 
vient après une grosse demi-heure de recherche. Donc, à utiliser avec 
précaution :) et ne pas hésiter à nous dire si je me suis planté ;)

En attendant, merci d'avoir apporté mon attention sur ce contrib, je 
crois que je vais l'utiliser à mon boulot. (Oups, en me relisant, je 
viens de me ré-apercevoir que 8.2-only, donc pas pour moi... pfff...).

Bon courage.


--
Guillaume.