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). 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 <red...@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@openstreetmap.org > https://lists.openstreetmap.org/listinfo/dev-fr >
_______________________________________________ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
