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 <[email protected] > <mailto:[email protected]>> 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 > [email protected] <mailto:[email protected]> > https://lists.openstreetmap.org/listinfo/dev-fr > > > > > -- > Christian Quest - OpenStreetMap France > > > _______________________________________________ > dev-fr mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/dev-fr > -- Christophe Merlet (RedFox) _______________________________________________ dev-fr mailing list [email protected] https://lists.openstreetmap.org/listinfo/dev-fr
