[OSM-dev-fr] "glonflement" des tables osm2pgsql...

[Christophe Merlet]

Le 12/08/2014 10:10, Christian Quest a écrit :
> Vu qu'on a 2 bases osm2pgsql monde à la structure identique sur les
> serveurs tile et layers, j'ai comparé l'espace occupé par les tables car
> celui-ci est compté actuellement sur nos SSD de 480 (tile) et 512Go
> (layers).
> 
> Il y a des différentes plus ou moins importantes. La plus étonnante
> concerne planet_osm_line qui pour les seules data fait 55Go sur tile et
> 39Go sur layers, soit une différence de 40%.
> 
> Je m'explique difficilement ces différences.
> 
> Je viens de recopier la table (CREATE TABLE line as SELECT * FROM
> planet_osm_line) et j'ai une table de 35Go. Il y a donc des trous dans
> les data ou alors c'est un auto-vacuum en cours qui provoque ce
> gonflement alors que je pensais qu'il prenait des données en fin de
> fichier pour les remettre dans les trous.
> 
> Des idées de votre côté ?


L'auto vacuum est extrêmement limité. Il ne fait qu'indiquer les espaces
réutilisables sans forcer leur réutilisation. C'est le VACUUM FULL qui
permet de regagné l'espace disque. Mais pour se faire il faut au moins
avoir l'équivalent de la plus grosse table en espace disponible et
verrouiller les  tables en cours de traitement.

Par ailleurs regagner l'espace disque n'est pas forcément une bonne
idée, car, si je ne m'abuse, pgsql essaye d'insérer les données "au bon
endroit". S'il y a des trous dans la base au bon endroit à cause d'une
suppression précédente, c'est gagné, sinon il met là ou il peut.

Ce sont les stats qui indique la meilleur stratégie.

D'ailleurs, suivant l'espace disque disponible, il peut être judicieux
de diminuer le fillfactor. ça laisse volontairement des trous dans la
base pour insérer les nouvelles données



	Librement,
-- 
Christophe Merlet (RedFox)