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 <[email protected] > <mailto:[email protected]>> 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 > [email protected] <mailto:[email protected]> > https://lists.openstreetmap.org/listinfo/dev-fr > > > > > _______________________________________________ > dev-fr mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/dev-fr > -- Christophe Merlet (RedFox) _______________________________________________ dev-fr mailing list [email protected] https://lists.openstreetmap.org/listinfo/dev-fr
