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

[Christophe Merlet]

Le 12/08/2014 21:38, Christian Quest a écrit :
> Le 12 août 2014 21:07, Christophe Merlet <redfox at redfoxcenter.org
> <mailto: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à.


Ho zut, je me suis trompé de lien oO rien à voir !!
C'est celui là
http://www.postgresql.org/message-id/482E80323A35A54498B8B70FF2B879800458C31048@azsmsx504.amr.corp.intel.com

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

C'est comme ça que je comprend la doc
http://www.postgresql.org/docs/current/static/sql-vacuum.html

"VACUUM reclaims storage occupied by dead tuples. In normal PostgreSQL
operation, tuples that are deleted or obsoleted by an update are not
physically removed from their table; they remain present until a VACUUM
is done. Therefore it's necessary to do VACUUM periodically, especially
on frequently-updated tables."


> 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


-- 
Christophe Merlet (RedFox)