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

[Christian Quest]

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 <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
> https://lists.openstreetmap.org/listinfo/dev-fr
>



-- 
Christian Quest - OpenStreetMap France
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/dev-fr/attachments/20140812/77db4a0d/attachment.html>