Commit 1e0b4365 authored by Alvaro Herrera's avatar Alvaro Herrera

Further code and wording tweaks in BRIN

Besides a couple of typo fixes, per David Rowley, Thom Brown, and Amit
Langote, and mentions of BRIN in the general CREATE INDEX page again per
David, this includes silencing MSVC compiler warnings (thanks Microsoft)
and an additional variable initialization per Coverity scanner.
parent 96a73fcd
......@@ -64,7 +64,7 @@
<title>Built-in Operator Classes</title>
<para>
The core <productname>PostgreSQL</productname> distribution includes
The core <productname>PostgreSQL</productname> distribution
includes the <acronym>BRIN</acronym> operator classes shown in
<xref linkend="brin-builtin-opclasses-table">.
</para>
......
......@@ -57,8 +57,8 @@ CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ] [ [ IF NOT EXISTS ] <replaceable class=
<para>
<productname>PostgreSQL</productname> provides the index methods
B-tree, hash, GiST, SP-GiST, and GIN. Users can also define their own index
methods, but that is fairly complicated.
B-tree, hash, GiST, SP-GiST, GIN, and BRIN. Users can also define their own
index methods, but that is fairly complicated.
</para>
<para>
......@@ -166,7 +166,8 @@ CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ] [ [ IF NOT EXISTS ] <replaceable class=
<para>
The name of the index method to be used. Choices are
<literal>btree</literal>, <literal>hash</literal>,
<literal>gist</literal>, <literal>spgist</> and <literal>gin</>.
<literal>gist</literal>, <literal>spgist</>, <literal>gin</>, and
<literal>brin</>.
The default method is <literal>btree</literal>.
</para>
</listitem>
......@@ -492,7 +493,7 @@ Indexes:
</caution>
<para>
Currently, only the B-tree, GiST and GIN index methods support
Currently, only the B-tree, GiST, GIN, and BRIN index methods support
multicolumn indexes. Up to 32 fields can be specified by default.
(This limit can be altered when building
<productname>PostgreSQL</productname>.) Only B-tree currently
......
......@@ -126,7 +126,7 @@ that page range is complete and new tuples belong in a new page range that
hasn't yet been summarized. Those insertions do not create a new index
entry; instead, the page range remains unsummarized until later.
Wehn VACUUM is run on the table, all unsummarized page ranges are
Whenever VACUUM is run on the table, all unsummarized page ranges are
summarized. This action can also be invoked by the user via
brin_summarize_new_values(). Both these procedures scan all the
unsummarized ranges, and create a summary tuple. Again, this includes the
......
......@@ -107,9 +107,11 @@ brininsert(PG_FUNCTION_ARGS)
BrinMemTuple *dtup;
BlockNumber heapBlk;
int keyno;
BrinTuple *tmptup PG_USED_FOR_ASSERTS_ONLY;
BrinMemTuple *tmpdtup PG_USED_FOR_ASSERTS_ONLY;
Size tmpsiz PG_USED_FOR_ASSERTS_ONLY;
#ifdef USE_ASSERT_CHECKING
BrinTuple *tmptup;
BrinMemTuple *tmpdtup;
Size tmpsiz;
#endif
CHECK_FOR_INTERRUPTS();
......
......@@ -95,7 +95,7 @@ brin_form_tuple(BrinDesc *brdesc, BlockNumber blkno, BrinMemTuple *tuple,
BrinTuple *rettuple;
int keyno;
int idxattno;
uint16 phony_infomask;
uint16 phony_infomask = 0;
bits8 *phony_nullbitmap;
Size len,
hoff,
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment