Il faudrait tout de même distinguer les "trous" libres laissés dans les pages (dépendants du "fill factor") des trous laissés par les pages totalement libres au sein du pool de pages occupé par une table ou un index dans la base.
Le mode de stockage aussi de la base globale intervient (trous dans un même tablespace), de même que la fragmentation ou la rapartition des pages alloues entre plusieurs tablespaces alloués sur des disques ou clusters de disques différents, sachant qu'un même tablespace peut mélanger des pages allouées pour des tables ou index différents. Le concept de tablespace intervient pour passer outre certaines limitations du système de fichiers utilisé pour y allouer physiquement les tablespaces (ces systèmes de fichiers étant eux aussi plus ou moins locaux avec des performances d'accès très différentes selon leur localisation et leur support physique, y compris sur un emplacement réseau). Une table de base de données n'est pas nécessairement associée bijectivement à un fichier physique du système de fichiers. et un tablespace peut aussi être monté directement dans une partition sans système de fichiers géré par l'OS (la base de données est déjà en elle-même un système de fichiers autonome avec son propre catalogue), mais la situation inverse existe aussi où un système de fichier possède tous les attributs d'une base de données. Le 12 août 2014 23:28, Christian Quest <cqu...@openstreetmap.fr> a écrit : > Le 12 août 2014 22:09, Christophe Merlet <red...@redfoxcenter.org> a > écrit : > > Le 12/08/2014 21:38, Christian Quest a écrit : >> > Le 12 août 2014 21:07, Christophe Merlet <red...@redfoxcenter.org >> > <mailto:red...@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/482e80323a35a54498b8b70ff2b879800458c31...@azsmsx504.amr.corp.intel.com >> >> > Mouais... un peu courte l'explication. > > UPDATE est équivalent à DELETE+INSERT vu d'en haut, mais vu d'en bas ça > m'étonnerai beaucoup que ça soit géré comme ça... show me the code ;) > > > 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." > > > Ok, un DELETE ou UPDATE peuvent laisser des trous, VACCUM les élimine. > Pour ça VACUUM va prendre des data en fin de fichier et les déplacer dans > les trous au fur et à mesure de son scan en remettant à jour les index vu > le déplacement des données. C'est ce que j'ai lu je ne sais plus où :( > VACUUM FULL procède autrement, il crée une copie de la table en recopiant > les tuples un à un sans recopier les trous. > > -- > Christian Quest - OpenStreetMap France > > _______________________________________________ > dev-fr mailing list > dev-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/dev-fr > >
_______________________________________________ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
