On Sat, Nov 8, 2014 at 8:56 AM, Alvaro Herrera <alvhe...@2ndquadrant.com>
wrote:
>
> I just pushed this, after some more minor tweaks. Thanks, and please do
> continue testing!
>
Please find attached another small fix. This time it's just a small typo in
the README, and just some updates to some, now outdated docs.
Kind Regards
David Rowley
diff --git a/doc/src/sgml/ref/create_index.sgml
b/doc/src/sgml/ref/create_index.sgml
index ead3375..18bd0d3 100644
--- a/doc/src/sgml/ref/create_index.sgml
+++ b/doc/src/sgml/ref/create_index.sgml
@@ -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
diff --git a/src/backend/access/brin/README b/src/backend/access/brin/README
index 2619be8..636d965 100644
--- a/src/backend/access/brin/README
+++ b/src/backend/access/brin/README
@@ -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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
