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

[Francescu GAROBY]

Et ça ne vaudrait pas le coup de modifier la fonction "pgsql_modify_node"
que tu pointes pour lui faire faire un UPDATE, plutôt qu'un INSERT/DELETE ?
La modification ne me paraît pas compliquée et si ça peut faciliter votre
histoire de fillfactor (j'avoue ne pas comprendre de quoi il s'agit)...

Francescu


Le 12 août 2014 12:47, Christian Quest <cquest at openstreetmap.fr> a écrit :

> 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
>
> _______________________________________________
> dev-fr mailing list
> dev-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev-fr
>
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/dev-fr/attachments/20140812/0811c0fb/attachment.html>