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

[Christophe Merlet]

Le 12/08/2014 20:44, Christian Quest a écrit :
> Ah bon, postgres n'essaye pas de faire un update "sur place" quand c'est
> possible ?

Non. UPDATE étant une opération de type DELETE/INSERT (
http://postgresql.todaysummary.com/q_postgresql_32709.html )

alors les mises à jour sont faites là où il y a de la place même avec un
CLUSTER.
http://www.postgresql.org/docs/9.3/interactive/sql-cluster.html
"Clustering is a one-time operation: when the table is subsequently
updated, the changes are not clustered. That is, no attempt is made to
store new or updated rows according to their index order."

SAUF si la table est CLUSTERé avec un fillfactor < 100 , ça peut rester
dans la même page.
"Also, setting the table's FILLFACTOR storage parameter to less than
100% can aid in preserving cluster ordering during updates, since
updated rows are kept on the same page if enough space is available there."


Bref, tant qu'un (auto)vacuum n'a pas indiqué explicitement qu'une
lignes est obsolete, son emplacement n'est pas dispo à la réutilisation
dans une page, même en cas d'UPDATE.

> 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
> <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
> 
> 
> 
> 
> -- 
> Christian Quest - OpenStreetMap France
> 
> 
> _______________________________________________
> dev-fr mailing list
> dev-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev-fr
> 


-- 
Christophe Merlet (RedFox)