Le 12 août 2014 21:07, Christophe Merlet <[email protected]> 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
_______________________________________________ dev-fr mailing list [email protected] https://lists.openstreetmap.org/listinfo/dev-fr
