Skip to content

Commit

Permalink
Traductions lors des derniers déplacements :)
Browse files Browse the repository at this point in the history
  • Loading branch information
@gleu
gleu committed Aug 26, 2021
1 parent fdb5a52 commit 9923a61
Show file tree
Hide file tree
Showing 13 changed files with 897 additions and 851 deletions.
189 changes: 99 additions & 90 deletions postgresql/gist.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -283,32 +283,34 @@ CREATE INDEX ON ma_table USING GIST (ma_colonne_inet inet_ops);

<para>
Une classe d'opérateur d'index <acronym>GiST</acronym> doit fournir cinq
méthodes, et cinq supplémentaires optionnelles. La précision de l'index est assurée par l'implantation des
méthodes <function>same</function>, <function>consistent</function>
et <function>union</function> alors que l'efficacité (taille et rapidité)
de l'index dépendra des méthodes <function>penalty</function> et
<function>picksplit</function>. Deux fonctions optionnelles sont
<function>compress</function> et <function>decompress</function>, qui
permettent à un index d'avoir des données internes de l'arbre d'un type
différent de ceux des données qu'il indexe. Les feuilles doivent être du
type des données indexées alors que les autres nœuds peuvent être de
n'importe quelle structure C (mais vous devez toujours suivre les règles
des types de données de <productname>PostgreSQL</productname> dans ce cas,
voir ce qui concerne <literal>varlena</literal> pour les données de taille
variable). Si le type de données interne de l'arbre existe au niveau SQL,
l'option <literal>STORAGE</literal> de la commande <command>CREATE OPERATOR
CLASS</command> peut être utilisée.
La huitième méthode, optionnelle, est <function>distance</function>, qui
est nécessaire si la classe d'opérateur souhaite supporter les parcours
ordonnées (intéressant dans le cadre des recherches du voisin-le-plus-proche,
méthodes, et cinq supplémentaires optionnelles. La précision de l'index
est assurée par l'implantation des méthodes <function>same</function>,
<function>consistent</function> et <function>union</function> alors que
l'efficacité (taille et rapidité) de l'index dépendra des méthodes
<function>penalty</function> et <function>picksplit</function>. Deux
fonctions optionnelles sont <function>compress</function> et
<function>decompress</function>, qui permettent à un index d'avoir des
données internes de l'arbre d'un type différent de ceux des données qu'il
indexe. Les feuilles doivent être du type des données indexées alors que
les autres nœuds peuvent être de n'importe quelle structure C (mais vous
devez toujours suivre les règles des types de données de
<productname>PostgreSQL</productname> dans ce cas, voir ce qui concerne
<literal>varlena</literal> pour les données de taille variable). Si le
type de données interne de l'arbre existe au niveau SQL, l'option
<literal>STORAGE</literal> de la commande <command>CREATE OPERATOR
CLASS</command> peut être utilisée. La huitième méthode, optionnelle, est
<function>distance</function>, qui est nécessaire si la classe d'opérateur
souhaite supporter les parcours ordonnées (intéressant dans le cadre des
recherches du voisin-le-plus-proche,
<foreignphrase>nearest-neighbor</foreignphrase>). La neuvième méthode,
optionnelle, nommée <function>fetch</function>, est nécessaire si la classe
d'opérateur souhaite supporter les parcours d'index seuls, sauf quand la
méthode <function>compress</function> est omise.
La dixième méthode, optionnelle, est <function>options</function> et est nécessaire
optionnelle, nommée <function>fetch</function>, est nécessaire si la
classe d'opérateur souhaite supporter les parcours d'index seuls, sauf
quand la méthode <function>compress</function> est omise. La dixième
méthode, optionnelle, est <function>options</function> et est nécessaire
si l'opérateur de classe fournit des paramètres définis par l'utilisateur.
The <function>sortsupport</function> method is also optional and is used to
speed up building a <acronym>GiST</acronym> index.
La méthode <function>sortsupport</function> est aussi optionnelle et est
utilisée pour accélérer la construction d'un index
<acronym>GiST</acronym>.
</para>

<variablelist>
Expand Down Expand Up @@ -1153,26 +1155,28 @@ my_compress(PG_FUNCTION_ARGS)
</listitem>
</varlistentry>

<varlistentry>
<term><function>sortsupport</function></term>
<listitem>
<para>
Returns a comparator function to sort data in a way that preserves
locality. It is used by <command>CREATE INDEX</command> and
<command>REINDEX</command> commands. The quality of the created index
depends on how well the sort order determined by the comparator function
preserves locality of the inputs.
</para>
<para>
The <function>sortsupport</function> method is optional. If it is not
provided, <command>CREATE INDEX</command> builds the index by inserting
each tuple to the tree using the <function>penalty</function> and
<function>picksplit</function> functions, which is much slower.
</para>
<varlistentry>
<term><function>sortsupport</function></term>
<listitem>
<para>
Renvoie une fonction de comparaison pour trier lesdonnées d'une façon
qui préserve l'emplacement. Elle est utilisée par les commandes
<command>CREATE INDEX</command> et <command>REINDEX</command>. La
qualité de l'index créé dépend decomment l'ordre de tri déterminé par
la fonction de comparaison préserve l'emplacement des entrées.
</para>

<para>
La méthode <function>sortsupport</function> est optionnelle. Si elle
n'est pas fournie, <command>CREATE INDEX</command> construit l'index en
insérant chaque ligne dans l'arbre en utilisant les fonctions
<function>penalty</function> et <function>picksplit</function>, qui
sont plus lentes.
</para>

<para>
The <acronym>SQL</acronym> declaration of the function must look like
this:
<para>
La déclaration <acronym>SQL</acronym> de la fonction doit ressembler à
ceci&nbsp;:

<programlisting>
CREATE OR REPLACE FUNCTION my_sortsupport(internal)
Expand All @@ -1181,26 +1185,28 @@ AS 'MODULE_PATHNAME'
LANGUAGE C STRICT;
</programlisting>

The argument is a pointer to a <structname>SortSupport</structname>
struct. At a minimum, the function must fill in its comparator field.
The comparator takes three arguments: two Datums to compare, and
a pointer to the <structname>SortSupport</structname> struct. The
Datums are the two indexed values in the format that they are stored
in the index; that is, in the format returned by the
<function>compress</function> method. The full API is defined in
<filename>src/include/utils/sortsupport.h</filename>.
</para>
L'argument est un pointeur vers une structure
<structname>SortSupport</structname>. Au minimum, la fonction doit
remplir son champ de comparaison. La fonction prends trois
arguments&nbsp;: deux Datums à comparer, et un pointeur vers la
structure <structname>SortSupport</structname>. Les Datums sont les
deux valeurs indexées dans le format où elles sont stockées dans
l'index&nbsp;; c'est-à-dire dans le format renvoyé par la méthode
<function>compress</function>. L'API complète est définie dans
<filename>src/include/utils/sortsupport.h</filename>.
</para>

<para>
The matching code in the C module could then follow this skeleton:
<para>
Le code correspondant dans un module C pourrait suivre ce
squelette&nbsp;:

<programlisting>
PG_FUNCTION_INFO_V1(my_sortsupport);

static int
my_fastcmp(Datum x, Datum y, SortSupport ssup)
{
/* establish order between x and y by computing some sorting value z */
/* établir l'ordre entre x et y en calculant une valeur de tri z */

int z1 = ComputeSpatialCode(x);
int z2 = ComputeSpatialCode(y);
Expand Down Expand Up @@ -1246,57 +1252,60 @@ my_sortsupport(PG_FUNCTION_ARGS)
<title>Implémentation</title>

<sect2 id="gist-buffering-build">
<title>GiST Index Build Methods</title>
<title>Méthodes de construction d'index GiST</title>

<para>
The simplest way to build a GiST index is just to insert all the entries,
one by one. This tends to be slow for large indexes, because if the
index tuples are scattered across the index and the index is large enough
to not fit in cache, a lot of random I/O will be
needed. <productname>PostgreSQL</productname> supports two alternative
methods for initial build of a GiST index: <firstterm>sorted</firstterm>
and <firstterm>buffered</firstterm> modes.
La façon la plus simple de construire un index GiST est justement
d'insérer toutes les entrées, une par une. Ceci tend à être lent pour les
index volumineux parce que, si les entrées d'index sont réparties partout
dans l'index et que l'index est suffisamment gros pour ne pas tenir en
cache, un grand nombre d'accès disque aléatoires seront nécessaires.
<productname>PostgreSQL</productname> accepte deux méthodes alternatives
pour une construction initiale d'un indexGiST&nbsp;: le mode
<firstterm>sorted</firstterm> (trié) et le mode
<firstterm>buffered</firstterm> (tampon).
</para>

<para>
The sorted method is only available if each of the opclasses used by the
index provides a <function>sortsupport</function> function, as described
in <xref linkend="gist-extensibility"/>. If they do, this method is
usually the best, so it is used by default.
La méthode par tri est seulement disponible si chacune des classes
d'opérateur utilisée par l'index fournit une fonction
<function>sortsupport</function>, comme décrit dans <xref
linkend="gist-extensibility"/>. Si c'est le cas, cette méthode est
généralement la meilleure, donc elle est utilisée par défaut.
</para>

<para>
The buffered method works by not inserting tuples directly into the index
right away. It can dramatically reduce the amount of random I/O needed
for non-ordered data sets. For well-ordered data sets the benefit is
smaller or non-existent, because only a small number of pages receive new
tuples at a time, and those pages fit in cache even if the index as a
whole does not.
La méthode par cache fonctionne en n'insérant pas les lignes directement
et immédiatement dans l'index. Il peut réduire fortement la quantité
d'accès disques aléatoires nécessaire pour les ensembles de données non
triés. Pour les ensembles de données bien triés, le bénéfice est plus
petit, voire inexistant car seul un petit nombre de blocs reçoit de
nouvelles lignes à un instant t, et ces blocs tiennent en cache même si
l'index complet ne le peut pas.
</para>

<para>
The buffered method needs to call the <function>penalty</function>
function more often than the simple method does, which consumes some
extra CPU resources. Also, the buffers need temporary disk space,
allant jusqu'à la taille de l'index
résultant. L'utilisation de tampons peut aussi influencer la qualité de
l'index résultant, de façon positive et négative. Cette influence dépend
de plusieurs facteurs, comme la distribution des données en entrée et de
l'implémentation de la classe d'opérateur.
La méthode par cache a besoin d'appeler la fonction
<function>penalty</function> plus souvent que ne le fait la méthode
simple, ce qui consomme des ressources CPU supplémentaires. De plus, le
cache a besoin d'un espace disque supplémentaire allant jusqu'à la taille
de l'index résultant. L'utilisation de tampons peut aussi influencer la
qualité de l'index résultant, de façon positive et négative. Cette
influence dépend de plusieurs facteurs, comme la distribution des données
en entrée et de l'implémentation de la classe d'opérateur.
</para>

<para>
If sorting is not possible, then by default a GiST index build switches
to the buffering method when the index size reaches
<xref linkend="guc-effective-cache-size"/>. Buffering can be manually
forced or prevented by the <literal>buffering</literal> parameter to the
CREATE INDEX command. The default behavior is good for most cases, but
turning buffering off might speed up the build somewhat if the input data
is ordered.
Si le tri n'est pas possible, alors par défaut la construction d'un index
GiST bascule sur la méthode par cache quand la taille de l'index atteint
<xref linkend="guc-effective-cache-size"/>. L'utilisation du cache peut
être forcée ou empêchée manuellement avec le paramètre
<literal>buffering</literal> de la commande CREATE INDEX. Le comportement
par défaut est bon dans la plupart des cas mais désactiver le cache
pourrait accélérer un peu la construction si les données en entrée sont
triées.
</para>

</sect2>

</sect1>

<sect1 id="gist-examples">
Expand Down

0 comments on commit 9923a61

Please sign in to comment.