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

[DANTE Alexandra <Alexandra(dot)Dante(at)bull(dot)net>]

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