Ah bon, postgres n'essaye pas de faire un update "sur place" quand c'est possible ?
Ca m'étonne quand même parce que ça impose de remettre à jour les différents index qui pointent vers l'enregistrement alors qu'un UPDATE sur place permettrai de l'éviter. Ceci dit, je n'ai aucune idée du fonctionnement interne de postgres... je suppute ;) Le 12 août 2014 18:36, Christophe Merlet <[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] > https://lists.openstreetmap.org/listinfo/dev-fr > -- Christian Quest - OpenStreetMap France
_______________________________________________ dev-fr mailing list [email protected] https://lists.openstreetmap.org/listinfo/dev-fr
