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

[Christian Quest]

Le 12 août 2014 21:07, Christophe Merlet <redfox at redfoxcenter.org> a écrit :

> 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 )
>
>
Marrant je n'ai pas la même lecture que toi... je ne vois pas de référence
au DELETE dans ces explications, juste une proposition pour faire
l'équivalent du REPLACE de mysql qui fait soit un INSERT soit un UPDATE si
la ligne existe déjà.



> 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."
>
>
Tel que je le comprends, ce "since updated rows are kept on the same page
if enough space is available there" ne me semble pas être lié au fait que
la table ait été CLUSTERisée ni lié à la valeur de fillfactor. Ca serait
assez logique d'un point de vue perf qu'un UPDATE d'une ligne essaye de le
faire dans la même page tant qu'à faire.

Je pense donc qu'un UPDATE est vraiment géré de façon différente d'un
DELETE, puis d'un INSERT qui sont traités de façon totalement indépendantes.

Même la mise à jour des index bénéficie d'un UPDATE sur place... seuls les
index concernant les colonnes modifiées ont dans ce cas besoin d'être remis
à jour si on fait ça bien, alors qu'avec un DELETE+INSERT il faudra les
mettre à jour eux aussi 2 fois systématiquement.

Un courageux pour jeter un oeil sur le code de postgres ? J'ai un peu
regardé... mais je me suis vite perdu ! :(


> 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.
>
>

auto-vacuum fonctionne-t-il réellement comme ça ? Je n'ai pas non plus
l'impression.

Quand efface une ligne, la fsm (free space map) est mise à jour pour la
page pour noter que de l'espace est dispo sur cette page. Quand postgres a
besoin d'espace il commence à regarder par là.
Il y a une extension qui permet d'explorer ça si on veut: pg_freespacemap


-- 
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/3261573c/attachment.html>