Le 12/08/2014 21:38, Christian Quest a écrit : > Le 12 août 2014 21:07, Christophe Merlet <[email protected] > <mailto:[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à.
Ho zut, je me suis trompé de lien oO rien à voir !! C'est celui là http://www.postgresql.org/message-id/482e80323a35a54498b8b70ff2b879800458c31...@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) _______________________________________________ dev-fr mailing list [email protected] https://lists.openstreetmap.org/listinfo/dev-fr
