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

[Christian Quest]

Par défaut le fillfactor sur les data est de 100%, d'où l'idée de le
baisser un peu... mais l'efficacité dépendra aussi de comment osm2pgsql met
à jour les données et vu le code ça semble malheureusement se faire à coup
de DELETE/INSERT et pas d'UPDATE...
https://github.com/openstreetmap/osm2pgsql/blob/master/output-pgsql.c#L1432

Je ne suis pas sûr dans ces conditions que ça serve à grand chose.


Le 12 août 2014 11:37, Christophe Merlet <redfox at redfoxcenter.org> a écrit :

> 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)
>
> _______________________________________________
> dev-fr mailing list
> dev-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev-fr
>



-- 
Christian Quest - OpenStreetMap France
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/dev-fr/attachments/20140812/03a76150/attachment.html>