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

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.