Skip to content

Commit

Permalink
Traduction des fichiers <50
Browse files Browse the repository at this point in the history
  • Loading branch information
@gleu
gleu committed Aug 18, 2021
1 parent 94855c5 commit a670c0d
Show file tree
Hide file tree
Showing 5 changed files with 252 additions and 234 deletions.
30 changes: 15 additions & 15 deletions postgresql/extend.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -299,8 +299,8 @@
<row>
<entry><type>anymultirange</type></entry>
<entry>Simple</entry>
<entry>Indicates that a function accepts any multirange data type
(see <xref linkend="rangetypes"/>)
<entry>Indique qu'une fonction accepte tout type de données multirange
(voir <xref linkend="rangetypes"/>)
</entry>
</row>

Expand Down Expand Up @@ -344,9 +344,9 @@
<row>
<entry><type>anycompatiblemultirange</type></entry>
<entry>Common</entry>
<entry>Indicates that a function accepts any multirange data type,
with automatic promotion of multiple arguments to a common data type
</entry>
<entry>Indique qu'une fonction accepte tout type de données multirange,
avec une promotion automatique de plusieurs arguments vers un type de
données commun</entry>
</row>
</tbody>
</tgroup>
Expand Down Expand Up @@ -395,16 +395,16 @@
</para>

<para>
Similarly, if there are positions declared <type>anyrange</type>
and others declared <type>anyelement</type> or <type>anyarray</type>,
the actual range type in the <type>anyrange</type> positions must be a
range whose subtype is the same type appearing in
the <type>anyelement</type> positions and the same as the element type
of the <type>anyarray</type> positions.
If there are positions declared <type>anymultirange</type>,
their actual multirange type must contain ranges matching parameters declared
<type>anyrange</type> and base elements matching parameters declared
<type>anyelement</type> and <type>anyarray</type>.
De façon similaire, S'il existe des positions déclarées
<type>anyrange</type> et d'autres déclarées <type>anyelement</type> ou
<type>anyarray</type>, le type intervalle réel dans les positions
<type>anyrange</type> doit être un intervalle dont le sous-type est le
même type apparaissant dans les positions <type>anyelement</type> et le
même que le type élément des positions <type>anyarray</type>. S'il existe
des positions déclarées <type>anymultirange</type>, leur type multirange
réel doit contenir des intervalles correspondant aux paramètres déclarés
<type>anyrange</type> et des éléments de base correspondant aux
paramètres déclarés <type>anyelement</type> et <type>anyarray</type>.
</para>

<para>
Expand Down
31 changes: 16 additions & 15 deletions postgresql/hstore.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -718,11 +718,11 @@ SELECT 'a=&gt;1,a=&gt;2'::hstore;
</table>

<para>
In addition to these operators and functions, values of
the <type>hstore</type> type can be subscripted, allowing them to act
like associative arrays. Only a single subscript of type <type>text</type>
can be specified; it is interpreted as a key and the corresponding
value is fetched or stored. For example,
En plus de ces opérateurs et fonctions, les valeurs du type
<type>hstore</type> peuvent utiliser des indices, leur permettant ainsi
d'agir comme des tableaux associatifs. Seul un indice simple de type
<type>text</type> peut être indiqué&nbsp;; il est interprété comme la clé,
et la valeur correspondante est récupérée ou stockée. Par exemple,

<programlisting><![CDATA[
CREATE TABLE mytable (h hstore);
Expand All @@ -741,13 +741,13 @@ SELECT h FROM mytable;
(1 row)
]]></programlisting>

A subscripted fetch returns <literal>NULL</literal> if the subscript
is <literal>NULL</literal> or that key does not exist in
the <type>hstore</type>. (Thus, a subscripted fetch is not greatly
different from the <literal>-&gt;</literal> operator.)
A subscripted update fails if the subscript is <literal>NULL</literal>;
otherwise, it replaces the value for that key, adding an entry to
the <type>hstore</type> if the key does not already exist.
Une lecture par indice renvoie <literal>NULL</literal> si l'indice est
<literal>NULL</literal> ou si la clé n'existe pas dans ce
<type>hstore</type>. (De ce fait, une lecture par indice n'est pas
fortement différente de l'opérateur <literal>-&gt;</literal>.) Une mise à
jour par indice échoue si l'indice est <literal>NULL</literal>&nbsp;;
sinon elle remplace la valeur pour cette clé, ajoutant une entrée au
<type>hstore</type> si la clé n'existe pas déjà.
</para>
</sect2>

Expand Down Expand Up @@ -810,11 +810,12 @@ CREATE INDEX hidx ON testhstore USING HASH (h);
valeur&nbsp;:
<programlisting>
UPDATE tab SET h['c'] = '3';</programlisting>
Another way to do the same thing is:
Voici une autre façon de faire la même chose&nbsp;:
<programlisting>
UPDATE tab SET h = h || hstore('c', '3');</programlisting>
If multiple keys are to be added or changed in one operation,
the concatenation approach is more efficient than subscripting:
Si plusieurs clés doivent être ajoutées ou modifiées en une seule
opération, l'approche par concaténation est plus efficace que par
indice&nbsp;:
<programlisting>
UPDATE tab SET h = h || hstore(array['q', 'w'], array['11', '12']);</programlisting>
</para>
Expand Down
61 changes: 30 additions & 31 deletions postgresql/indices.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -117,14 +117,15 @@
d'index utilise un algorithme différent qui convient à un type
particulier de requêtes. Par défaut, la commande <link
linkend="sql-createindex"><command>CREATE INDEX</command></link> crée un
index B-tree, ce qui convient dans la plupart des situations. The other
index types are selected by writing the keyword <literal>USING</literal>
followed by the index type name. For example, to create a Hash index:
index B-tree, ce qui convient dans la plupart des situations. Les autres
types d'index sont sélectionnés en écrivant le mot clé
<literal>USING</literal> suivi du nom du type d'index. Par exemple, pour
créer un index hash&nbsp;:
<programlisting>
CREATE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable> USING HASH (<replaceable>column</replaceable>);
</programlisting>
</para>

<sect2 id="indexes-types-btree">
<title>B-Tree</title>

Expand Down Expand Up @@ -190,14 +191,14 @@ CREATE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable>
<see>index</see>
</indexterm>

<para>
Hash indexes store a 32-bit hash code derived from the
value of the indexed column. Hence,
such indexes can only handle simple equality comparisons.
Le planificateur de requêtes considère l'utilisation d'un index hash quand
une colonne indexée est impliquée dans une comparaison avec l'opérateur
d'égalité&nbsp;: <synopsis>=</synopsis>
</para>
<para>
Les index Hash enregistrent un code de hachage sur 32 bits dérivé de la
valeur d'une colonne indexée. De ce fait, de tels index peuvent seulement
gérer des comparaisons simples d'égalité. Le planificateur de requêtes
considère l'utilisation d'un index hash quand une colonne indexée est
impliquée dans une comparaison avec l'opérateur d'égalité&nbsp;:
<synopsis>=</synopsis>
</para>
</sect2>

<sect2 id="indexes-type-gist">
Expand Down Expand Up @@ -353,17 +354,16 @@ SELECT * FROM places ORDER BY location <-> point '(101,456)' LIMIT 10;

<para>
Les index BRIN (raccourci pour <foreignphrase>Block Range
INdexes</foreignphrase>) stockent des résumés sur les valeurs enregistrées
dans des blocs physiques successifs de la table.
Thus, they are most effective for columns whose values are well-correlated
with the physical order of the table rows.
Comme GiST, SP-GiST et
GIN, BRIN supporte plusieurs stratégies d'indexation, et les opérateurs
compatibles avec un index BRIN varient suivant la stratégie d'indexation.
Pour les types de données qui ont un ordre de tri linéaire, la donnée
indexée correspond aux valeurs minimale et maximale des valeurs de la
colonne pour chaque ensemble de blocs. Cela supporte les requêtes indexées
utilisant ces opérateurs&nbsp;:
INdexes</foreignphrase>) stockent des résumés sur les valeurs enregistrées
dans des blocs physiques successifs de la table. De ce fait, ils sont plus
efficaces pour les colonnes dont les valeurs sont corrélées avec l'ordre
physique des lignes dans la table. Comme GiST, SP-GiST et GIN, BRIN
supporte plusieurs stratégies d'indexation, et les opérateurs compatibles
avec un index BRIN varient suivant la stratégie d'indexation. Pour les
types de données qui ont un ordre de tri linéaire, la donnée indexée
correspond aux valeurs minimale et maximale des valeurs de la colonne pour
chaque ensemble de blocs. Cela supporte les requêtes indexées utilisant
ces opérateurs&nbsp;:

<synopsis>
&lt; &nbsp; &lt;= &nbsp; = &nbsp; &gt;= &nbsp; &gt;
Expand Down Expand Up @@ -404,14 +404,13 @@ SELECT * FROM places ORDER BY location <-> point '(101,456)' LIMIT 10;
</para>

<para>
Actuellement, seuls les types d'index B-tree, GiST, GIN et BRIN supportent les
index multicolonnes. Whether there can be multiple key
columns is independent of whether <literal>INCLUDE</literal> columns
can be added to the index. Indexes can have up to 32 columns,
including <literal>INCLUDE</literal> columns.
Cette limite peut être modifiée à la compilation de
<productname>PostgreSQL</productname>. Voir le fichier
<filename>pg_config_manual.h</filename>.
Actuellement, seuls les types d'index B-tree, GiST, GIN et BRIN supportent
les index multicolonnes. Qu'il puisse y avoir plusieurs colonnes clés est
indépendant de si les colonnes <literal>INCLUDE</literal> peuvent être
ajoutées à l'index. Les index peuvent avoir jusqu'à 32 colonnes en
incluant les colonnes <literal>INCLUDE</literal>. Cette limite peut être
modifiée à la compilation de <productname>PostgreSQL</productname>. Voir
le fichier <filename>pg_config_manual.h</filename>.
</para>

<para>
Expand Down
112 changes: 61 additions & 51 deletions postgresql/ref/create_index.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -404,31 +404,38 @@
choisie.
</para>
<para>
B-tree indexes on tables where many inserts and/or updates are
anticipated can benefit from lower fillfactor settings at
<command>CREATE INDEX</command> time (following bulk loading into the
table). Values in the range of 50 - 90 can usefully <quote>smooth
out</quote> the <emphasis>rate</emphasis> of page splits during the
early life of the B-tree index (lowering fillfactor like this may even
lower the absolute number of page splits, though this effect is highly
workload dependent). The B-tree bottom-up index deletion technique
described in <xref linkend="btree-deletion"/> is dependent on having
some <quote>extra</quote> space on pages to store <quote>extra</quote>
tuple versions, and so can be affected by fillfactor (though the effect
is usually not significant).
Les index B-tree sur des tables où de nombreuses insertions et/ou mises
à jour sont prévues peuvent bénéficier d'un facteur de remplissage
plus bas lors du <command>CREATE INDEX</command> (suivant le
chargement en masse dans la table). Les valeurs dans l'intervalle 50 -
90 peut utilement <quote>diminuer</quote> le <emphasis>taux</emphasis>
de division de blocs au début de la vie de l'index B-tree
(baisser ainsi le facteur de remplissage peut même diminuer le nombre
absolu de divisions de blocs, bien que cet effet est fortement
dépendant de la charge de travail). La technique de suppression de
l'index B-Tree du bas vers le haut décrite dans <xref
linkend="btree-deletion"/> est dépendent sur la place
<quote>supplémentaire</quote> disponible dans les blocs pour des
versions <quote>supplémentaires</quote> de lignes, et ainsi peut être
affectée par le facteur de remplissage (bien que l'effet n'est
habituellement pas significatif).
</para>
<para>
In other specific cases it might be useful to increase fillfactor to
100 at <command>CREATE INDEX</command> time as a way of maximizing
space utilization. You should only consider this when you are
completely sure that the table is static (i.e. that it will never be
affected by either inserts or updates). A fillfactor setting of 100
otherwise risks <emphasis>harming</emphasis> performance: even a few
updates or inserts will cause a sudden flood of page splits.
Dans les autres cas spécifiques, il pourrait être utile d'augmenter le
facteur de remplissage à 100 au moment du <command>CREATE
INDEX</command> comme moyen de maximiser l'utilisation de l'espace.
Vous devez seulement le considérer quand vous êtes complètement sûr
que la table est statique(autrement dit qu'elle ne sera jamais
affectée par des insertions ou des mises à jour). Une configuration du
facteur de remplissage à 100 risque autrement de
<emphasis>baisser</emphasis> les performances&nbsp;: même un petit
nombre de mises à jour ou d'insertions peut causer une soudaine
explosion des divisions de blocs.
</para>
<para>
The other index methods use fillfactor in different but roughly
analogous ways; the default fillfactor varies between methods.
Les autres méthodes d'index utilisent le facteur de remplissage de
façon différente mais grossièrement identique&nbsp;; le facteur de
remplissage par défaut varie suivant les méthodes.
</para>
</listitem>
</varlistentry>
Expand Down Expand Up @@ -482,14 +489,15 @@
<listitem>
<para>
Détermine si la technique de construction par tampon décrite dans <xref
linkend="gist-buffering-build"/> est utilisé pour construire l'index. À
<literal>OFF</literal>, cette technique est désactivée. À
linkend="gist-buffering-build"/> est utilisé pour construire l'index.
À <literal>OFF</literal>, cette technique est désactivée. À
<literal>ON</literal>, elle est activée. À <literal>AUTO</literal>,
elle est initialement désactivée mais peut être activée quand la taille
de l'index atteint <xref linkend="guc-effective-cache-size"/>. La
valeur par défaut est <literal>AUTO</literal>.
Note that if sorted build is possible, it will be used instead of
buffered build unless <literal>buffering=ON</literal> is specified.
elle est initialement désactivée mais peut être activée quand la
taille de l'index atteint <xref linkend="guc-effective-cache-size"/>.
La valeur par défaut est <literal>AUTO</literal>. Notez que si la
construction triée est possible, elle sera utilisée à la place de la
construction par tampon à moins que <literal>buffering=ON</literal> ne
soit spécifié.
</para>
</listitem>
</varlistentry>
Expand Down Expand Up @@ -650,17 +658,18 @@
table interviennent dans deux transactions supplémentaires. Avant chaque
parcours de table, la construction de l'index doit attendre la fin des
transactions en cours qui ont modifié la table. Après le deuxième
parcours, la construction doit attendre la fin de toute transactions ayant
une image de base (un snapshot, voir <xref linkend="mvcc"/>) datant
parcours, la construction doit attendre la fin de toute transactions
ayant une image de base (un snapshot, voir <xref linkend="mvcc"/>) datant
d'avant le deuxième parcours pour se terminer, ceci incluant les
transactions utilisées par toute phase des constructions concurrentes
d'index sur les autres tables, if the indexes involved are partial or have
columns that are not simple column references. Ensuite, l'index peut être marqué comme
utilisable, et la commande <command>CREATE INDEX</command> se termine.
Néanmoins, même après cela, l'index pourrait ne pas être immédiatement
utilisable pour les autres requêtes&nbsp;: dans le pire des cas, il ne
peut pas être utilisé tant que des transactions datant d'avant le début de
la création de l'index existent.
d'index sur les autres tables, si les index impliqués sont partiels ou
ont des colonnes qui ne sont pas des références de colonne simple.
Ensuite, l'index peut être marqué comme utilisable, et la commande
<command>CREATE INDEX</command> se termine. Néanmoins, même après cela,
l'index pourrait ne pas être immédiatement utilisable pour les autres
requêtes&nbsp;: dans le pire des cas, il ne peut pas être utilisé tant
que des transactions datant d'avant le début de la création de l'index
existent.
</para>

<para>
Expand Down Expand Up @@ -738,14 +747,14 @@
</para>

<para>
Actuellement, seules les méthodes d'indexation B-tree, GiST, GIN et BRIN supportent les
index multi-colonnes. Whether there can be multiple key
columns is independent of whether <literal>INCLUDE</literal> columns
can be added to the index. Indexes can have up to 32 columns,
including <literal>INCLUDE</literal> columns.
(Cette limite peut être modifiée à la compilation de
<productname>PostgreSQL</productname>.) Seul B-tree supporte actuellement les
index uniques.
Actuellement, seules les méthodes d'indexation B-tree, GiST, GIN et BRIN
supportent les index multi-colonnes. Qu'il puisse y avoir plusieurs
colonnes clés est indépendant du fait que des colonnes
<literal>INCLUDE</literal> puissent être ajoutées à l'index. Les index
peuvent avoir jusqu'à 32 colonnes, ceci incluant les colonnes
<literal>INCLUDE</literal>.(Cette limite peut être modifiée à la
compilation de <productname>PostgreSQL</productname>.) Seul B-tree
supporte actuellement les index uniques.
</para>

<para>
Expand Down Expand Up @@ -895,9 +904,9 @@
<para>
Comme pour toute transaction longue, <command>CREATE INDEX</command> sur
une table peut affecter les lignes pouvant être supprimées par un
<command>VACUUM</command> concurrent sur toute autre table.
Excepted from this are operations with the <literal>CONCURRENTLY</literal>
option for indexes that are not partial and do not index any expressions.
<command>VACUUM</command> concurrent sur toute autre table. En dehors de
ceci, il y a des opérations avec l'option <literal>CONCURRENTLY</literal>
pour des index non partiels et sans expressions.
</para>

<para>
Expand All @@ -910,9 +919,10 @@
</para>

<para>
Each backend running <command>CREATE INDEX</command> will report its
progress in the <structname>pg_stat_progress_create_index</structname>
view. See <xref linkend="create-index-progress-reporting"/> for details.
Chaque processus exécutant un <command>CREATE INDEX</command> indiquera sa
progression dans la vue
<structname>pg_stat_progress_create_index</structname>. Voir <xref
linkend="create-index-progress-reporting"/> pour les détails.
</para>
</refsect1>

Expand Down

0 comments on commit a670c0d

Please sign in to comment.