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

Bonjour Guillaume, bonjour à tous,

J'ai refait un test ce matin sur la table "warehouse" de ma base de
données pour vérifier le champ "relblocknumber".
Comme dans le cas de la table "ditrict", cette table n'a subi que des
insertions, aucune mise à jour ni suppression de données.
Cette table contient 10 lignes, stockées dans une page :
base=# \d warehouse
Table "public.warehouse"
Column | Type | Modifiers
------------+-----------------------+-----------
w_id | integer | not null
w_ytd | numeric(12,2) |
w_tax | numeric(4,4) |
w_name | character varying(10) |
w_street_1 | character varying(20) |
w_street_2 | character varying(20) |
w_city | character varying(20) |
w_state | character(2) |
w_zip | character(9) |
Indexes:
"pk_warehouse" PRIMARY KEY, btree (w_id), tablespace "index_tbs"
Tablespace: "misc_tbs"

base=# select relname,relnamespace,relfilenode ,relpages ,reltuples from
pg_class where relname='warehouse';
relname | relnamespace | relfilenode | relpages | reltuples
-----------+--------------+-------------+----------+-----------
warehouse | 2200 | 16411 | 1 | 10
(1 row)

La vue "pg_freespacemap_relations" nous indique :
base=# SELECT c.relname, r.avgrequest, r.interestingpages, r.storedpages
base-# FROM pg_freespacemap_relations r INNER JOIN pg_class c
base-# ON c.relfilenode = r.relfilenode INNER JOIN
pg_database d
base-# ON r.reldatabase = d.oid AND (d.datname =
current_database())
base-# ORDER BY r.storedpages DESC LIMIT 10;
relname | avgrequest | interestingpages | storedpages
------------+------------+------------------+-------------
warehouse | 253 | 1 | 1

La vue "pg_freespacemap_pages" renvoie :
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='warehouse';
relname | relblocknumber | bytes
-----------+----------------+-------
warehouse | 0 | 6568
(1 row)

=> Puisque ma table est stockée sur 1 page, le décompte utilisé pour
définir le champ "relblocknumber" semble bien commencer à 0.
=> Si je reviens à l'exemple de la table "ditrict", stockée sur 3 pages,
la requête ci-dessus nous renvoyait "relblocknumber = 2", ce qui
signifie que les octets libres appartenaient bien à la page n°3.

Bonne journée,
Alexandra

Guillaume Lelarge wrote:

> 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 :)
>
>