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 <[email protected]> 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 <[email protected]> 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 >> [email protected] >> https://lists.openstreetmap.org/listinfo/dev-fr >> > > > > -- > Christian Quest - OpenStreetMap France > > _______________________________________________ > dev-fr mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/dev-fr > >
_______________________________________________ dev-fr mailing list [email protected] https://lists.openstreetmap.org/listinfo/dev-fr
