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

[Christophe Merlet]

Le 12/08/2014 18:47, Philippe Verdy a écrit :
> DELETE/INSERT la plupart du temps va réutiliser la page dans laquelle il
> vient de créer un trou, mais au passage il peut aussi utiliser n'importe
> quelle autre page déjà en mémoire si cette autre page permet un meilleur
> équilbrage de l'arbre que de réutiliser l'ancienne page: le but est
> d'équilibrer les trous dans les pages pour éviter de se retrouver dans
> le cas au pire (le pire cas c'est une insertion au milieu d'une page
> déjà pleine, quand toutes les pages racines sont déjà pleines, ce qui
> arrive justement après une compression maximale de la table: c'est là
> qu'on a le plus d'I/O puisqu'il faut non seulement scinder la page en
> deux, lire les pages voisines avant et après, et restructurer aussi les
> pages parentes dans l'arbre de la même façon).
> 
> Je n'ai pas eu souvent à mettre dans une base SQL un fill factor
> supérieur à 85% (au moins pour les pages feuilles). pour les tables de
> données, ni supérieur à 95% pour les index secondaires à clé courte. 97%
> est un taux exceptionnel et au delà ça rame dès qu'il y a plus de 3 ou 4
> accès concurrents (même en lecture, à cause des nombreux locks de pages
> causés sur une grande partie des pages y compris les pages mères, et à
> cause des volumes d'I/O).

Je te signale quand même que PostgreSQL a un fillfactor par defaut de
100 pour les data et de 90 pour les index B-tree. J'imagine que les dev
auraient choisi d'autres valeurs si cela était si impactant sur les
performances.

Il serait plus intéressant que tu donnes les bonnes valeurs à utiliser
dans le cas d'une base mapnik monde mise à jour toutes les minutes...


> Si on veut une base rapide, on doit accepter qu'il y ait des "trous" à
> un taux raisonnable dans les tables volumineuses ayant de nombreux accès
> concurrents (surtout que pour ce type de base on à toutes sortes de
> types d'accès: séquentiels comme aléatoires, par une grande diversité de
> requêtes utilisant des filtres très différents, et des sélectivités de
> clés imprévisibles dans les données OSM).
> 
> 
> 
> Le 12 août 2014 18:36, Christophe Merlet <redfox at redfoxcenter.org
> <mailto:redfox at redfoxcenter.org>> a écrit :
> 
>     Le 12/08/2014 17:30, Francescu GAROBY a écrit :
>     > Je pensais plutôt à tester la présence (via un SELECT sur
>     l'osm_id, qui
>     > doit être un champ indexé, je suppose...) et, selon la réponse, à
>     faire
>     > un INSERT ou un UPDATE.
>     > Si un SELECT est sensiblement aussi rapide qu'un DELETE, et un INSERT
>     > aussi rapide qu'un UPDATE, tu ne verras pas de différence notable
>     sur le
>     > temps de traitement, mais tu auras résolu ton problème de trous de
>     partout.
>     >
>     > Francescu,
>     > (qui est développeur, pas DBA)
> 
>     Généralement DELETE/INSERT est plus rapide que UPDATE. Et de ce que j'ai
>     pu lire sur pgsql,  UPDATE execute en interne un DELETE/INSERT avec donc
>     la création de trou dans la base.
> 
> 
>             Librement,
>     --
>     Christophe Merlet (RedFox)
> 
>     _______________________________________________
>     dev-fr mailing list
>     dev-fr at openstreetmap.org <mailto:dev-fr at openstreetmap.org>
>     https://lists.openstreetmap.org/listinfo/dev-fr
> 
> 
> 
> 
> _______________________________________________
> dev-fr mailing list
> dev-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev-fr
> 


-- 
Christophe Merlet (RedFox)