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

Merci Guillaume pour votre réponse très complète !

J'ai continué d'expérimenter pg_freespacemap et j'ai lancé la requête
que vous m'aviez conseillée :
base=# SELECT c.relname, p.relblocknumber, p.bytes
base-# FROM pg_freespacemap_pages p INNER JOIN pg_class c
base-# ON c.relfilenode = p.relfilenode INNER JOIN
pg_database d
base-# ON (p.reldatabase = d.oid AND d.datname =
current_database())
base-# WHERE c.relname='district';
relname | relblocknumber | bytes
----------+----------------+-------
district | 2 | 7304
(1 row)

Donc si je ne me trompe pas, cela signifie que la page n°2 contient 7304
octets de libre, ce qui explique que pg_freespacemap_relations trouve
une page dont l'espace libre dépasse avgrequest.

Le champ "storedPages" est encore un peu obscur pour moi, je vais
essayer de creuser la question.

Bonne soirée,
Alexandra

Guillaume Lelarge wrote:

> 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.
>
>