Mise à jour en version 10.15

postgresql/advanced.xml

@@ -626,22 +626,22 @@ CREATE VIEW villes AS
 );
 
 CREATE TABLE capitales (
-  etat      char(2)
+  etat      char(2) UNIQUE NOT NULL
 ) INHERITS (villes);</programlisting>
    </para>
 
    <para>
     Dans ce cas, une ligne de <classname>capitales</classname>
     <firstterm>hérite</firstterm> de toutes les colonnes
     (<structfield>nom</structfield>, <structfield>population</structfield> et
-    <structfield>elevation</structfield>) de son <firstterm>parent</firstterm>,
-    <classname>villes</classname>. Le type de la colonne
-    <structfield>nom</structfield> est <type>text</type>, un type natif de
-    <productname>PostgreSQL</productname> pour les chaînes de caractères à
-    longueur variable. La table <classname>capitales</classname> a une colonne supplémentaire,
-    <structfield>etat</structfield>, qui affiche l'état dont elles sont la
-    capitale. Sous <productname>PostgreSQL</productname>, une table peut
-    hériter de zéro à plusieurs autres tables.
+    <structfield>elevation</structfield>) de son
+    <firstterm>parent</firstterm>, <classname>villes</classname>. Le type de
+    la colonne <structfield>nom</structfield> est <type>text</type>, un type
+    natif de <productname>PostgreSQL</productname> pour les chaînes de
+    caractères à longueur variable. La table <classname>capitales</classname>
+    a une colonne supplémentaire, <structfield>etat</structfield>, qui affiche
+    l'abréviation de cet état. Sous <productname>PostgreSQL</productname>, une
+    table peut hériter de zéro à plusieurs autres tables.
    </para>
 
    <para>

postgresql/biblio.xml

@@ -121,8 +121,8 @@
   </biblioentry>
 
   <biblioentry id="ull88">
-   <title>Principles of Database and Knowledge</title>
-   <subtitle>Base Systems</subtitle>
+   <title>Principles of Database and Knowledge-Base Systems</title>
+   <subtitle>Classical Database Systems</subtitle>
    <authorgroup>
     <author>
      <firstname>Jeffrey D.</firstname>

postgresql/bloom.xml

@@ -1,6 +1,4 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!-- doc/src/sgml/bloom.sgml -->
-
 <sect1 id="bloom" xreflabel="bloom">
  <title>bloom</title>
 
@@ -118,76 +116,69 @@ CREATE INDEX bloomidx ON tbloom USING bloom (i1,i2,i3)
    FROM
   generate_series(1,10000000);
 SELECT 10000000
-=# CREATE INDEX bloomidx ON tbloom USING bloom (i1, i2, i3, i4, i5, i6);
-CREATE INDEX
-=# SELECT pg_size_pretty(pg_relation_size('bloomidx'));
- pg_size_pretty
-----------------
- 153 MB
-(1 row)
-=# CREATE index btreeidx ON tbloom (i1, i2, i3, i4, i5, i6);
-CREATE INDEX
-=# SELECT pg_size_pretty(pg_relation_size('btreeidx'));
- pg_size_pretty
-----------------
- 387 MB
-(1 row)
 </programlisting>
 
   <para>
    Un parcours séquentiel sur cette grande table prend beaucoup de temps&nbsp;:
 <programlisting>
 =# EXPLAIN ANALYZE SELECT * FROM tbloom WHERE i2 = 898732 AND i5 = 123451;
-                                                 QUERY PLAN
-------------------------------------------------------------------------------------------------------------
- Seq Scan on tbloom  (cost=0.00..213694.08 rows=1 width=24) (actual time=1445.438..1445.438 rows=0 loops=1)
+                                              QUERY PLAN
+------------------------------------------------------------------------------------------------------
+ Seq Scan on tbloom  (cost=0.00..2137.14 rows=3 width=24) (actual time=19.059..19.060 rows=0 loops=1)
    Filter: ((i2 = 898732) AND (i5 = 123451))
-   Rows Removed by Filter: 10000000
- Planning time: 0.177 ms
- Execution time: 1445.473 ms
+   Rows Removed by Filter: 100000
+ Planning time: 0.269 ms
+ Execution time: 19.077 ms
 (5 rows)
 </programlisting>
   </para>
 
   <para>
-   En général, l'optimiseur sélectionnera un parcours d'index si c'est
-   possible. Avec un index btree, nous obtenons ceci&nbsp;:
+   Même avec l'index btree défini, le résultat sera toujours un parcours
+   séquentiel&nbsp;:
 <programlisting>
+=# CREATE INDEX btreeidx ON tbloom (i1, i2, i3, i4, i5, i6);
+CREATE INDEX
+=# SELECT pg_size_pretty(pg_relation_size('btreeidx'));
+ pg_size_pretty
+----------------
+ 3992 kB
+(1 row)
 =# EXPLAIN ANALYZE SELECT * FROM tbloom WHERE i2 = 898732 AND i5 = 123451;
-                                                           QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------
- Index Only Scan using btreeidx on tbloom  (cost=0.56..298311.96 rows=1 width=24) (actual time=445.709..445.709 rows=0 loops=1)
-   Index Cond: ((i2 = 898732) AND (i5 = 123451))
-   Heap Fetches: 0
- Planning time: 0.193 ms
- Execution time: 445.770 ms
-(5 rows)
+                                              QUERY PLAN
+------------------------------------------------------------------------------------------------------
+ Seq Scan on tbloom  (cost=0.00..2137.00 rows=2 width=24) (actual time=15.070..15.070 rows=0 loops=1)
+   Filter: ((i2 = 898732) AND (i5 = 123451))
+   Rows Removed by Filter: 100000
+ Planning time: 0.130 ms
+ Execution time: 15.083 ms
 </programlisting>
   </para>
 
   <para>
-   Bloom est meilleur que btree pour gérer ce type de recherche&nbsp;:
+   Avoir un index bloom défini sur la table est préférable à un btree pour
+   gérer ce type de recherche&nbsp;:
 <programlisting>
+=# CREATE INDEX bloomidx ON tbloom USING bloom (i1, i2, i3, i4, i5, i6);
+CREATE INDEX
+=# SELECT pg_size_pretty(pg_relation_size('bloomidx'));
+ pg_size_pretty
+----------------
+ 1584 kB
+(1 row)
 =# EXPLAIN ANALYZE SELECT * FROM tbloom WHERE i2 = 898732 AND i5 = 123451;
-                                                        QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------
- Bitmap Heap Scan on tbloom  (cost=178435.39..178439.41 rows=1 width=24) (actual time=76.698..76.698 rows=0 loops=1)
+                                                     QUERY PLAN
+---------------------------------------------------------------------------------------------------------------------
+ Bitmap Heap Scan on tbloom  (cost=1792.00..1799.69 rows=2 width=24) (actual time=0.456..0.456 rows=0 loops=1)
    Recheck Cond: ((i2 = 898732) AND (i5 = 123451))
-   Rows Removed by Index Recheck: 2439
-   Heap Blocks: exact=2408
-   -&gt;  Bitmap Index Scan on bloomidx  (cost=0.00..178435.39 rows=1 width=0) (actual time=72.455..72.455 rows=2439 loops=1)
+   Rows Removed by Index Recheck: 29
+   Heap Blocks: exact=27
+   -&gt;  Bitmap Index Scan on bloomidx  (cost=0.00..1792.00 rows=2 width=0) (actual time=0.422..0.423 rows=29 loops=1)
          Index Cond: ((i2 = 898732) AND (i5 = 123451))
- Planning time: 0.475 ms
- Execution time: 76.778 ms
+ Planning time: 0.105 ms
+ Execution time: 0.477 ms
 (8 rows)
  </programlisting>
-   Noter le nombre relativement important de faux positifs&nbsp;: 2349 lignes
-   ont été sélectionnées pour vérification dans la table, mais aucune ne correspondait 
-   au filtre de la requête. Nous pouvons réduire cela en
-   spécifiant une longueur de signature plus importante. Dans cet exemple,
-   créer l'index avec <literal>length=200</literal> a réduit le nombre de faux
-   positifs à 55 mais doublé la taille de l'index (306 Mo) et
-   s'est révélé plus lent pour cette requête (125 ms en tout).
   </para>
 
   <para>
@@ -197,24 +188,37 @@ CREATE INDEX
    est de créer un index séparé pour chaque colonne. À ce moment-là,
    l'optimiseur pourra choisir quelque chose comme&nbsp;:
 <programlisting>
+=# CREATE INDEX btreeidx1 ON tbloom (i1);
+CREATE INDEX
+=# CREATE INDEX btreeidx2 ON tbloom (i2);
+CREATE INDEX
+=# CREATE INDEX btreeidx3 ON tbloom (i3);
+CREATE INDEX
+=# CREATE INDEX btreeidx4 ON tbloom (i4);
+CREATE INDEX
+=# CREATE INDEX btreeidx5 ON tbloom (i5);
+CREATE INDEX
+=# CREATE INDEX btreeidx6 ON tbloom (i6);
+CREATE INDEX
 =# EXPLAIN ANALYZE SELECT * FROM tbloom WHERE i2 = 898732 AND i5 = 123451;
-                                                          QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------
- Bitmap Heap Scan on tbloom  (cost=9.29..13.30 rows=1 width=24) (actual time=0.148..0.148 rows=0 loops=1)
+                                                        QUERY PLAN
+---------------------------------------------------------------------------------------------------------------------------
+ Bitmap Heap Scan on tbloom  (cost=24.34..32.03 rows=2 width=24) (actual time=0.029..0.029 rows=0 loops=1)
    Recheck Cond: ((i5 = 123451) AND (i2 = 898732))
-   -&gt;  BitmapAnd  (cost=9.29..9.29 rows=1 width=0) (actual time=0.145..0.145 rows=0 loops=1)
-         -&gt;  Bitmap Index Scan on tbloom_i5_idx  (cost=0.00..4.52 rows=11 width=0) (actual time=0.089..0.089 rows=10 loops=1)
+   -&gt;  BitmapAnd  (cost=24.34..24.34 rows=2 width=0) (actual time=0.028..0.028 rows=0 loops=1)
+         -&gt;  Bitmap Index Scan on btreeidx5  (cost=0.00..12.04 rows=500 width=0) (actual time=0.027..0.027 rows=0 loops=1)
                Index Cond: (i5 = 123451)
-         -&gt;  Bitmap Index Scan on tbloom_i2_idx  (cost=0.00..4.52 rows=11 width=0) (actual time=0.048..0.048 rows=8 loops=1)
+         -&gt;  Bitmap Index Scan on btreeidx2  (cost=0.00..12.04 rows=500 width=0) (never executed)
                Index Cond: (i2 = 898732)
- Planning time: 2.049 ms
- Execution time: 0.280 ms
+ Planning time: 0.389 ms
+ Execution time: 0.054 ms
 (9 rows)
  </programlisting>
-   Bien que cette requête soit bien plus rapide qu'avec n’importe lequel des index à une colonne,
-   nous payons une large pénalité en taille d'index. Chacun des
-   index btree mono-colonne occupe 214 Mo, soit un espace total de plus de
-   1,2 Go, autrement dit huit fois la place utilisée par l'index bloom.
+   Bien que cette requête soit bien plus rapide qu'avec n’importe lequel des
+   index à une colonne,
+   nous payons une pénalité en taille d'index. Chacun des
+   index btree mono-colonne occupe 2 Mo, soit un espace total de plus de
+   12 Mo, autrement dit huit fois la place utilisée par l'index bloom.
   </para>
  </sect2>
 

postgresql/catalogs.xml

@@ -9278,14 +9278,15 @@ SCRAM-SHA-256$<replaceable>&lt;nombre d'itération&gt;</replaceable>:<replaceabl
    Il existe plusieurs types distincts d'objets verrouillables&nbsp;: les
    relations complètes (tables, par exemple), les pages individuelles de
    relations, des tuples individuels de relations, les identifiants de
-   transaction (virtuels et permanents) et les objets généraux de la base
-   de données (identifiés par
-   l'OID de la classe et l'OID de l'objet, de la même façon que dans
-   <structname>pg_description</structname> ou
+   transaction (virtuels et permanents) et les objets généraux de la base de
+   données (identifiés par l'OID de la classe et l'OID de l'objet, de la même
+   façon que dans <structname>pg_description</structname> ou
    <structname>pg_depend</structname>). De plus, le droit d'étendre une
-   relation est représenté comme un objet verrouillable distinct. Et
-   enfin, les verrous informatifs peuvent être pris sur les numéros qui
-   ont la signification définie par l'utilisateur.
+   relation est représenté comme un objet verrouillable distinct, tout comme
+   le droit de mettre à jour
+   <structname>pg_database</structname>.<structfield>datfrozenxid</structfield>.
+   Et enfin, les verrous informatifs peuvent être pris sur les numéros qui ont
+   la signification définie par l'utilisateur.
   </para>
 
   <table>
@@ -9313,6 +9314,7 @@ SCRAM-SHA-256$<replaceable>&lt;nombre d'itération&gt;</replaceable>:<replaceabl
        Type de l'objet verrouillable&nbsp;:
        <literal>relation</literal>,
        <literal>extend</literal>,
+       <literal>frozenid</literal>,
        <literal>page</literal>,
        <literal>tuple</literal>,
        <literal>transactionid</literal>,

postgresql/charset.xml

@@ -823,12 +823,12 @@ CREATE COLLATION german (provider = libc, locale = 'de_DE');
      </varlistentry>
 
      <varlistentry>
-      <term><literal>CREATE COLLATION digitslast (provider = icu, locale = 'en-u-kr-latn-digit');</literal></term>
-      <term><literal>CREATE COLLATION digitslast (provider = icu, locale = 'en@colReorder=latn-digit');</literal></term>
+      <term><literal>CREATE COLLATION latinlast (provider = icu, locale = 'en-u-kr-grek-latn');</literal></term>
+      <term><literal>CREATE COLLATION latinlast (provider = icu, locale = 'en@colReorder=grek-latn');</literal></term>
       <listitem>
        <para>
-        Trie les chiffres après les lettres latines. (Par défaut, les chiffres
-        sont avant les lettres.)
+        Trie les lettres grecques après les lettres latines. (Par défaut, les
+        lettres latines sont avant les lettres grecques.)
        </para>
       </listitem>
      </varlistentry>
@@ -845,8 +845,8 @@ CREATE COLLATION german (provider = libc, locale = 'de_DE');
      </varlistentry>
 
      <varlistentry>
-      <term><literal>CREATE COLLATION special (provider = icu, locale = 'en-u-kf-upper-kr-latn-digit');</literal></term>
-      <term><literal>CREATE COLLATION special (provider = icu, locale = 'en@colCaseFirst=upper;colReorder=latn-digit');</literal></term>
+      <term><literal>CREATE COLLATION special (provider = icu, locale = 'en-u-kf-upper-kr-grek-latn');</literal></term>
+      <term><literal>CREATE COLLATION special (provider = icu, locale = 'en@colCaseFirst=upper;colReorder=grek-latn');</literal></term>
       <listitem>
        <para>
         Combine ces deux options.