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
