mirror of
https://github.com/postgres/postgres.git
synced 2025-06-08 22:02:03 +03:00
Fix English in bloom module documentation
Author: Erik Rijkers
This commit is contained in:
parent
9ee014fc89
commit
a361c22ebf
@ -8,32 +8,32 @@
|
|||||||
</indexterm>
|
</indexterm>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
<literal>bloom</> is a contrib which implements index access method. It comes
|
<literal>bloom</> is a module which implements an index access method. It comes
|
||||||
as example of custom access methods and generic WAL records usage. But it
|
as an example of custom access methods and generic WAL records usage. But it
|
||||||
is also useful itself.
|
is also useful in itself.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<sect2>
|
<sect2>
|
||||||
<title>Introduction</title>
|
<title>Introduction</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Implementation of
|
The implementation of a
|
||||||
<ulink url="http://en.wikipedia.org/wiki/Bloom_filter">Bloom filter</ulink>
|
<ulink url="http://en.wikipedia.org/wiki/Bloom_filter">Bloom filter</ulink>
|
||||||
allows fast exclusion of non-candidate tuples.
|
allows fast exclusion of non-candidate tuples via signatures.
|
||||||
Since signature is a lossy representation of all indexed attributes,
|
Since a signature is a lossy representation of all indexed attributes,
|
||||||
search results should be rechecked using heap information.
|
search results must be rechecked using heap information.
|
||||||
User can specify signature length (in uint16, default is 5) and the number of
|
The user can specify signature length (in uint16, default is 5) and the
|
||||||
bits, which can be setted, per attribute (1 < colN < 2048).
|
number of bits, which can be set per attribute (1 < colN < 2048).
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
This index is useful if table has many attributes and queries can include
|
This index is useful if a table has many attributes and queries include
|
||||||
their arbitary combinations. Traditional <literal>btree</> index is faster
|
arbitrary combinations of them. A traditional <literal>btree</> index is
|
||||||
than bloom index, but it'd require too many indexes to support all possible
|
faster than a bloom index, but it can require many indexes to support all
|
||||||
queries, while one need only one bloom index. Bloom index supports only
|
possible queries where one needs only a single bloom index. A Bloom index
|
||||||
equality comparison. Since it's a signature file, not a tree, it always
|
supports only equality comparison. Since it's a signature file, and not a
|
||||||
should be readed fully, but sequentially, so index search performance is
|
tree, it always must be read fully, but sequentially, so that index search
|
||||||
constant and doesn't depend on a query.
|
performance is constant and doesn't depend on a query.
|
||||||
</para>
|
</para>
|
||||||
</sect2>
|
</sect2>
|
||||||
|
|
||||||
@ -41,7 +41,8 @@
|
|||||||
<title>Parameters</title>
|
<title>Parameters</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
<literal>bloom</> indexes accept following parameters in <literal>WITH</>
|
<literal>bloom</> indexes accept the following parameters in the
|
||||||
|
<literal>WITH</>
|
||||||
clause.
|
clause.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
@ -71,7 +72,7 @@
|
|||||||
<title>Examples</title>
|
<title>Examples</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Example of index definition is given below.
|
An example of an index definition is given below.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
@ -80,12 +81,12 @@ CREATE INDEX bloomidx ON tbloom(i1,i2,i3)
|
|||||||
</programlisting>
|
</programlisting>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Here, we create bloom index with signature length 80 bits and attributes
|
Here, we created a bloom index with a signature length of 80 bits,
|
||||||
i1, i2 mapped to 2 bits, attribute i3 - to 4 bits.
|
and attributes i1 and i2 mapped to 2 bits, and attribute i3 to 4 bits.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Example of index definition and usage is given below.
|
Here is a fuller example of index definition and usage:
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
@ -142,7 +143,7 @@ SELECT pg_relation_size('btree_idx');
|
|||||||
</programlisting>
|
</programlisting>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Btree index will be not used for this query.
|
A btree index will be not used for this query.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
@ -162,10 +163,10 @@ SELECT pg_relation_size('btree_idx');
|
|||||||
<title>Opclass interface</title>
|
<title>Opclass interface</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Bloom opclass interface is simple. It requires 1 supporting function:
|
The Bloom opclass interface is simple. It requires 1 supporting function:
|
||||||
hash function for indexing datatype. And it provides 1 search operator:
|
a hash function for the indexing datatype. It provides 1 search operator:
|
||||||
equality operator. The example below shows <literal>opclass</> definition
|
the equality operator. The example below shows <literal>opclass</>
|
||||||
for <literal>text</> datatype.
|
definition for <literal>text</> datatype.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
@ -183,16 +184,16 @@ DEFAULT FOR TYPE text USING bloom AS
|
|||||||
<itemizedlist>
|
<itemizedlist>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
For now, only opclasses for <literal>int4</>, <literal>text</> comes
|
For now, only opclasses for <literal>int4</>, <literal>text</> come
|
||||||
with contrib. However, users may define more of them.
|
with the module. However, users may define more of them.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Only <literal>=</literal> operator is supported for search now. But it's
|
Only the <literal>=</literal> operator is supported for search at the
|
||||||
possible to add support of arrays with contains and intersection
|
moment. But it's possible to add support for arrays with contains and
|
||||||
operations in future.
|
intersection operations in the future.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
@ -203,15 +204,18 @@ DEFAULT FOR TYPE text USING bloom AS
|
|||||||
<title>Authors</title>
|
<title>Authors</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Teodor Sigaev <email>teodor@postgrespro.ru</email>, Postgres Professional, Moscow, Russia
|
Teodor Sigaev <email>teodor@postgrespro.ru</email>,
|
||||||
|
Postgres Professional, Moscow, Russia
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Alexander Korotkov <email>a.korotkov@postgrespro.ru</email>, Postgres Professional, Moscow, Russia
|
Alexander Korotkov <email>a.korotkov@postgrespro.ru</email>,
|
||||||
|
Postgres Professional, Moscow, Russia
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Oleg Bartunov <email>obartunov@postgrespro.ru</email>, Postgres Professional, Moscow, Russia
|
Oleg Bartunov <email>obartunov@postgrespro.ru</email>,
|
||||||
|
Postgres Professional, Moscow, Russia
|
||||||
</para>
|
</para>
|
||||||
</sect2>
|
</sect2>
|
||||||
|
|
||||||
|
Loading…
x
Reference in New Issue
Block a user