Re: Re: [pgsql-fr-generale] A ugmentation de taille incontrôlée d'une base

[Francois Suter <fsuter(at)cobweb(dot)ch>]

Salut,

> Tu as des suppressions ou des modifications de données ?

En temps normal, environ 180'000 UPDATE, plus un peu d'INSERT et de  
DELETE.

> Parce qu'un simple import ne peut expliquer des tables qui  
> explosent (à moins que le gros import se fasse dans une transaction  
> qui foire quelque fois).

Tiens, c'est intéressant, ça. L'import est effectivement dans une  
transaction et il y a eu récemment des plantées pour manque d'espace  
disque. Cela laisserait-il de gros espaces bloqués mais inutiles? Et  
si oui, comment les récupérer?

> Vu la quantité de table et d'index, seul max_fsm_pages compte. Il  
> indique le nombre de pages à surveiller. Le moyen le plus simple  
> pour connaître cette valeur est de récupérer la taille de toutes  
> les bases et de diviser par 8 Ko (une page disque fait 8 Ko).  
> L'autre moyen est d'exécuter cette requête sur chaque base (y  
> compris les bases systèmes) :
>
>   SELECT sum(relpages) FROM pg_class WHERE relkind IN ('r', 't', 'i');

Merci pour toutes ces explications. En faisant cela, j'arrive à  
environ 13'000 Ko, ce qui devrait être ok puisque le défaut est de  
20'000, non?

Par contre, si je prends la taille des bases, c'est une autre paire  
de manches, puisqu'elles ont justement une taille tout à fait  
déraisonnable (820 Mo, contre ~50 Mo pour une copie locale propre).  
Mais je vais déjà voir avec la mise à jour en 7.4.19...

A+

François Suter

--
Cobweb Development Sàrl
www.cobweb.ch

Rue Eugène-Marziano 15, CH-1227 Les Acacias (Geneva - Switzerland)
T: +41 22 880 00 93, F: +41 22 880 00 94, E: support(at)cobweb(dot)ch
web solutions for professionnal requirements

Attachment: smime.p7s
Description: S/MIME cryptographic signature