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

DANTE Alexandra a ecrit le 17/01/2007 18:26:
> Merci Guillaume pour votre réponse très complète !
>

De rien.

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

Je suis étonné que cela soit la page 2. Ou alors ils commencent le
décompte à 0 mais cette explication n'arrive pas vraiment à me convaincre.

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

Le FSM ne suit pas toutes les pages d'une relation. De même, il ne suit
pas toutes les relations. Une relation n'est tracée qu'à partir du
moment où il est fait appel à GetPageWithFreeSpace. Ensuite, tout dépend
du paramétrage de max_fsm_relations. Si le nombre de relations tracées
arrive à max_fsm_relations, la prochaine relation virera la relation la
moins utilisée dans le FSM. Pour gagner de la place, le nombre de pages
tracées semble suivre le même procédé. Mais bon, sur ce point, je n'ai
pas encore trop détaillé.

Ce contrib est quand même diablement intéressant. Un peu comme
pgstattuple... Dommage qu'il ne soit pas dispo en 8.1.

Dernier point, le FSM est dumpé dans un fichier à l'arrêt du serveur. Il
sera relu au lancement par la suite. Il s'agit de global/pg_fsm.cache.

> Bonne soirée,

De même :)

--
Guillaume.