[Trad] [svn:pgfr] r1353 - traduc/trunk/postgresql
admin at listes.postgresql.fr
admin at listes.postgresql.fr
Mer 24 Juin 19:11:09 CEST 2009
Author: gleu
Date: 2009-06-24 19:11:09 +0200 (Wed, 24 Jun 2009)
New Revision: 1353
Modified:
traduc/trunk/postgresql/gist.xml
traduc/trunk/postgresql/storage.xml
Log:
Suite de la traduction de la RC2.
Modified: traduc/trunk/postgresql/gist.xml
===================================================================
--- traduc/trunk/postgresql/gist.xml 2009-06-23 22:14:31 UTC (rev 1352)
+++ traduc/trunk/postgresql/gist.xml 2009-06-24 17:11:09 UTC (rev 1353)
@@ -56,6 +56,7 @@
fonctionnement interne de la base de données, tel que le gestionnaire de
verrous ou le WAL.
</para>
+
<para>
L'interface <acronym>GiST</acronym> dispose d'un haut niveau
d'abstraction, ce qui autorise le codeur de la méthode d'accès à
@@ -121,7 +122,6 @@
see about <literal>varlena</literal> for variable sized data). If the tree's
internal data type exists at the SQL level, the <literal>STORAGE</literal> option
of the <command>CREATE OPERATOR CLASS</command> command can be used.
-
</para>
<variablelist>
@@ -151,7 +151,8 @@
</para>
<para>
- The <acronym>SQL</acronym> declaration of the function must look like this:
+ La déclaration <acronym>SQL</acronym> de la fonction doit ressembler à
+ ceci :
<programlisting>
CREATE OR REPLACE FUNCTION my_consistent(internal, data_type, smallint, oid, internal)
@@ -160,7 +161,8 @@
LANGUAGE C STRICT;
</programlisting>
- And the matching code in the C module could then follow this skeleton:
+ Et le code correspondant dans le module C peut alors suivre ce
+ squelette :
<programlisting>
Datum my_consistent(PG_FUNCTION_ARGS);
@@ -192,13 +194,14 @@
}
</programlisting>
- Here, <varname>key</varname> is an element in the index and <varname>query</varname>
- the value being looked up in the index. The <literal>StrategyNumber</literal>
- parameter indicates which operator of your operator class is being
- applied — it matches one of the operator numbers in the
- <command>CREATE OPERATOR CLASS</command> command. Depending on what operators
- you have included in the class, the data type of <varname>query</varname> could
- vary with the operator, but the above skeleton assumes it doesn't.
+ Ici, <varname>key</varname> est un élément dans l'index et
+ <varname>query</varname> la valeur la recherchée dans l'index. Le
+ paramètre <literal>StrategyNumber</literal> indique l'opérateur
+ appliqué de votre classe d'opérateur. Il correspond à un des nombres
+ d'opérateurs dans la commande <command>CREATE OPERATOR CLASS</command>.
+ Suivant les opérateurs que vous avez inclus dans la classe, le type de
+ données de <varname>query</varname> pourrait varier avec l'opérateur,
+ mais le squelette ci-dessus suppose que ce n'est pas le cas.
</para>
</listitem>
@@ -208,13 +211,14 @@
<term><function>union</function></term>
<listitem>
<para>
- This method consolidates information in the tree. Given a set of
- entries, this function generates a new index entry that represents
- all the given entries.
+ Cette méthode consolide l'information dans l'arbre. Suivant un ensemble
+ d'entrées, cette fonction génère une nouvelle entrée d'index qui
+ représente toutes les entrées données.
</para>
<para>
- The <acronym>SQL</acronym> declaration of the function must look like this:
+ La déclaration <acronym>SQL</acronym> de la fonction doit ressembler à
+ ceci :
<programlisting>
CREATE OR REPLACE FUNCTION my_union(internal, internal)
@@ -223,7 +227,8 @@
LANGUAGE C STRICT;
</programlisting>
- And the matching code in the C module could then follow this skeleton:
+ Et le code correspondant dans le module C peut alors suivre ce
+ squelette :
<programlisting>
Datum my_union(PG_FUNCTION_ARGS);
@@ -264,17 +269,18 @@
</para>
<para>
- As you can see, in this skeleton we're dealing with a data type
- where <literal>union(X, Y, Z) = union(union(X, Y), Z)</literal>. It's easy
- enough to support data types where this is not the case, by
- implementing the proper union algorithm in this
- <acronym>GiST</acronym> support method.
+ Comme vous pouvez le voir dans ce quelette, nous gérons un type de
+ données où <literal>union(X, Y, Z) = union(union(X, Y), Z)</literal>.
+ C'est assez simple pour supporter les types de données où ce n'est pas
+ le cas, en implantant un autre algorithme d'union dans cette méthode
+ de support <acronym>GiST</acronym>.
</para>
<para>
- The <function>union</function> implementation function should return a
- pointer to newly <function>palloc()</function>ed memory. You can't just
- return whatever the input is.
+ La fonction d'implantation de <function>union</function> doit renvoyer
+ un pointeur vers la mémoire qui vient d'être allouée via la fonction
+ <function>palloc()</function>. Vous ne pouvez pas tout simplement
+ renvoyer l'entrée.
</para>
</listitem>
</varlistentry>
@@ -288,7 +294,8 @@
</para>
<para>
- The <acronym>SQL</acronym> declaration of the function must look like this:
+ La déclaration <acronym>SQL</acronym> de la fonction doit ressembler à
+ ceci :
<programlisting>
CREATE OR REPLACE FUNCTION my_compress(internal)
@@ -297,7 +304,8 @@
LANGUAGE C STRICT;
</programlisting>
- And the matching code in the C module could then follow this skeleton:
+ Et le code correspondant dans le module C peut alors suivre ce
+ squelette :
<programlisting>
Datum my_compress(PG_FUNCTION_ARGS);
@@ -332,15 +340,15 @@
</para>
<para>
- You have to adapt <replaceable>compressed_data_type</replaceable> to the specific
- type you're converting to in order to compress your leaf nodes, of
- course.
+ Vous devez adapter <replaceable>compressed_data_type</replaceable> au type
+ spécifique que vous essayez d'obtenir pour compresser les nœuds
+ finaux.
</para>
<para>
- Depending on your needs, you could also need to care about
- compressing <literal>NULL</literal> values in there, storing for example
- <literal>(Datum) 0</literal> like <literal>gist_circle_compress</literal> does.
+ Vous pourriez aussi avoir besoin de faire attention à la compression des
+ valeurs <literal>NULL</literal>, en enregistrant par exemple
+ <literal>(Datum) 0</literal> comme le fait <literal>gist_circle_compress</literal>.
</para>
</listitem>
</varlistentry>
@@ -355,7 +363,8 @@
</para>
<para>
- The <acronym>SQL</acronym> declaration of the function must look like this:
+ La déclaration <acronym>SQL</acronym> de la fonction doit ressembler à
+ ceci :
<programlisting>
CREATE OR REPLACE FUNCTION my_decompress(internal)
@@ -364,7 +373,8 @@
LANGUAGE C STRICT;
</programlisting>
- And the matching code in the C module could then follow this skeleton:
+ Et le code correspondant dans le module C peut alors suivre ce
+ squelette :
<programlisting>
Datum my_decompress(PG_FUNCTION_ARGS);
@@ -377,8 +387,8 @@
}
</programlisting>
- The above skeleton is suitable for the case where no decompression
- is needed.
+ Le squelette ci-dessus est convenable dans le cas iù aucune
+ décompression n'est nécessaire.
</para>
</listitem>
</varlistentry>
@@ -394,7 +404,8 @@
</para>
<para>
- The <acronym>SQL</acronym> declaration of the function must look like this:
+ La déclaration <acronym>SQL</acronym> de la fonction doit ressembler à
+ ceci :
<programlisting>
CREATE OR REPLACE FUNCTION my_penalty(internal, internal, internal)
@@ -403,7 +414,8 @@
LANGUAGE C STRICT; -- in some cases penalty functions need not be strict
</programlisting>
- And the matching code in the C module could then follow this skeleton:
+ Et le code correspondant dans le module C peut alors suivre ce
+ squelette :
<programlisting>
Datum my_penalty(PG_FUNCTION_ARGS);
@@ -425,10 +437,11 @@
</para>
<para>
- The <function>penalty</function> function is crucial to good performance of
- the index. It'll get used at insertion time to determine which branch
- to follow when choosing where to add the new entry in the tree. At
- query time, the more balanced the index, the quicker the lookup.
+ La fonction <function>penalty</function> est crucial pour de bonnes
+ performances de l'index. Elle sera utilisée lors de l'insertion pour
+ déterminer la branche à suivre pour savoir où ajoter la nouvelle entrée
+ dans l'arbre. Lors de l'exécution de la requête, plus l'arbre sera bien
+ balancé, plus l'exécution sera rapide.
</para>
</listitem>
</varlistentry>
@@ -437,13 +450,14 @@
<term><function>picksplit</function></term>
<listitem>
<para>
- When an index page split is necessary, this function decides which
- entries on the page are to stay on the old page, and which are to move
- to the new page.
+ Quand une division de page est nécessaire pour un index, cette fonction
+ décide des entrées de la page qui resteront sur l'ancienne page et de
+ celles qui seront déplacées sur la nouvelle page.
</para>
<para>
- The <acronym>SQL</acronym> declaration of the function must look like this:
+ La déclaration <acronym>SQL</acronym> de la fonction doit ressembler à
+ ceci :
<programlisting>
CREATE OR REPLACE FUNCTION my_picksplit(internal, internal)
@@ -452,7 +466,8 @@
LANGUAGE C STRICT;
</programlisting>
- And the matching code in the C module could then follow this skeleton:
+ Et le code correspondant dans le module C peut alors suivre ce
+ squelette :
<programlisting>
Datum my_picksplit(PG_FUNCTION_ARGS);
@@ -533,11 +548,11 @@
</para>
<para>
- Like <function>penalty</function>, the <function>picksplit</function> function
- is crucial to good performance of the index. Designing suitable
- <function>penalty</function> and <function>picksplit</function> implementations
- is where the challenge of implementing well-performing
- <acronym>GiST</acronym> indexes lies.
+ Comme <function>penalty</function>, la fonction <function>picksplit</function>
+ est cruciale pour de bonnes performances de l'index. Concevoir des
+ implantations convenables des fonctions <function>penalty</function> et
+ <function>picksplit</function> est le challenge d'un index
+ <acronym>GiST</acronym> performant.
</para>
</listitem>
</varlistentry>
@@ -546,11 +561,12 @@
<term><function>same</function></term>
<listitem>
<para>
- Returns true if two index entries are identical, false otherwise.
+ Renvoit true si les deux entrées de l'index sont identiques, faux sinon.
</para>
<para>
- The <acronym>SQL</acronym> declaration of the function must look like this:
+ La déclaration <acronym>SQL</acronym> de la fonction ressemble à
+ ceci :
<programlisting>
CREATE OR REPLACE FUNCTION my_same(internal, internal, internal)
@@ -559,7 +575,8 @@
LANGUAGE C STRICT;
</programlisting>
- And the matching code in the C module could then follow this skeleton:
+ Et le code correspondant dans le module C peut alors suivre ce
+ squelette :
<programlisting>
Datum my_same(PG_FUNCTION_ARGS);
@@ -577,9 +594,9 @@
}
</programlisting>
- For historical reasons, the <function>same</function> function doesn't
- just return a boolean result; instead it has to store the flag
- at the location indicated by the third argument.
+ Pour des raisons historiques, la fonction <function>same</function> ne
+ renvoie pas seulement un résultat booléen ; à la place, il doit
+ enregistrer le drapeau à l'emplacement indiqué par le troisième argument.
</para>
</listitem>
</varlistentry>
Modified: traduc/trunk/postgresql/storage.xml
===================================================================
--- traduc/trunk/postgresql/storage.xml 2009-06-23 22:14:31 UTC (rev 1352)
+++ traduc/trunk/postgresql/storage.xml 2009-06-24 17:11:09 UTC (rev 1353)
@@ -459,32 +459,33 @@
<sect1 id="storage-vm">
-<title>Visibility Map</title>
+<title>Carte de visibilité</title>
<indexterm>
- <primary>Visibility Map</primary>
+ <primary>Carte de visibilité</primary>
</indexterm>
-<indexterm><primary>VM</primary><see>Visibility Map</see></indexterm>
+<indexterm><primary>VM</primary><see>Carte de visibilité</see></indexterm>
<para>
-Each heap relation has a Visibility Map
-(VM) to keep track of which pages contain only tuples that are known to be
-visible to all active transactions. It's stored
-alongside the main relation data in a separate relation fork, named after the
-filenode number of the relation, plus a <literal>_vm</literal> suffix. For example,
-if the filenode of a relation is 12345, the VM is stored in a file called
-<filename>12345_vm</filename>, in the same directory as the main relation file.
-Note that indexes do not have VMs.
+Chaque relation a une carte de visibilité (<acronym>VM</acronym> acronyme de
+<foreignphrase>Visibility Map</foreignphrase>) pour garder trace des pages
+contenant seulement des lignes connues pour être visibles par toutes les
+transactions actives. Elle est stockée en dehors du fichier de données dans
+un fichier séparé nommé suivant le numéro relfilenode de la relation, auquel
+est ajouté le suffixe <literal>_vm</literal>. Par exemple, si le relfilenode
+de la relation est 12345, la VM est stockée dans un fichier appelé
+<filename>12345_vm</filename>, dans le même répertoire que celui du fichier
+de données. Notez que les index n'ont pas de VM.
</para>
<para>
-The visibility map simply stores one bit per heap page. A set bit means
-that all tuples on the page are known to be visible to all transactions.
-This means that the page does not contain any tuples that need to be vacuumed;
-in future it might also be used to avoid visiting the page for visibility
-checks. The map is conservative in the sense that we
-make sure that whenever a bit is set, we know the condition is true, but if
-a bit is not set, it might or might not be true.
+La carte de visibilité enregistre un bit par page. Un bit à 1 signifie
+que toutes les lignes de la page sont visibles par toutes les transactions.
+Cela signifie que le page ne contient pas de lignes nécessitant un VACUUM ;
+dans le futur, cela pourra aussi être utilisé pour éviter de visiter la page
+lors de vérifications de visibilité. Chaque fois qu'un bit est à 1, la condition
+est vraie à coup sûr. Par contre, dans le cas contraire, la condition peut être
+vraie comme fausse.
</para>
</sect1>
Plus d'informations sur la liste de diffusion Trad