Teodor,
Attached is a diff -c against your original gindocs patch. I did my
best not to change any of the semantics. My changes no doubt overlap
conflict with those Jeff Davis sent you earlier, so consider both of our
diffs.
Thanks,
Dave Fuhry
Teodor Sigaev wrote:
Patch adds GIN documentation and slightly improves GiST docs.
Somebody of native English speakers, pls, check the text... Thank you.
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
*** gindocs.orig 2006-09-17 00:21:38.0 -0400
--- gindocs 2006-09-17 00:57:12.0 -0400
***
*** 22,28
! /indexterm
! listitem
! para
! ! Soft upper limit of the size of the returned set by GIN index. For more
! information see xref linkend=gin-tips.
! /para
! /listitem
--- 22,28
! /indexterm
! listitem
! para
! ! Soft upper limit of the size of the set returned by the GIN index. For more
! information see xref linkend=gin-tips.
! /para
! /listitem
***
*** 88,95
+ para
+acronymGIN/acronym stands for Generalized Inverted Index. It is
+an index structure storing a set of (key, posting list) pairs, where
! +'posting list' is a set of rows in which the key occurs. The
! +row may contains a lot of keys.
+ /para
+
+ para
--- 88,95
+ para
+acronymGIN/acronym stands for Generalized Inverted Index. It is
+an index structure storing a set of (key, posting list) pairs, where
! +'posting list' is a set of rows in which the key occurs. Each
! +row may contain many keys.
+ /para
+
+ para
***
*** 178,184
+ listitem
+ para
+ Returns an array of keys of the query to be executed. n contains
! + strategy number of operation (see xref linkend=xindex-strategies).
+ Depending on n, query may be different type.
+ /para
+ /listitem
--- 178,184
+ listitem
+ para
+ Returns an array of keys of the query to be executed. n contains
! + the strategy number of the operation (see xref linkend=xindex-strategies).
+ Depending on n, query may be different type.
+ /para
+ /listitem
***
*** 188,196
+ termbool consistent( bool check[], StrategyNumber n, Datum query)/term
+ listitem
+ para
! + Returns TRUE if indexed value satisfies query qualifier with strategy n
+ (or may satisfy in case of RECHECK mark in operator class).
! + Each element of the check array is TRUE if indexed value has a
+ corresponding key in the query: if (check[i] == TRUE ) the i-th key of
+ the query is present in the indexed value.
+ /para
--- 188,196
+ termbool consistent( bool check[], StrategyNumber n, Datum query)/term
+ listitem
+ para
! + Returns TRUE if the indexed value satisfies the query qualifier with strategy n
+ (or may satisfy in case of RECHECK mark in operator class).
! + Each element of the check array is TRUE if the indexed value has a
+ corresponding key in the query: if (check[i] == TRUE ) the i-th key of
+ the query is present in the indexed value.
+ /para
***
*** 209,218
+termCreate vs insert/term
+listitem
+ para
! + In most cases, insertion into acronymGIN/acronym index is slow enough
! + due to a lot keys should be inserted per one value. So, for bulk upload
! + data in table it will be useful to drop index and create it
! + after finishing upload.
+ /para
+/listitem
+ /varlistentry
--- 209,218
+termCreate vs insert/term
+listitem
+ para
! + In most cases, insertion into a acronymGIN/acronym index is slow
! + due to the likelihood of many keys being inserted for each value. So, for bulk insertions into a
! + table it is advisable to to drop the GIN index and recreate it
! + after finishing bulk insertion.
+ /para
+/listitem
+ /varlistentry
***
*** 221,227
+termgin_fuzzy_search_limit/term
+listitem
+ para
! + The primary goal of development acronymGIN/acronym indices was
+ support for highly scalable, full-text search in
+ productnamePostgreSQL/productname and there are often situations when
+ a full-text search returns a very large set of results. Since reading
--- 221,227
+termgin_fuzzy_search_limit/term
+listitem
+ para
! + The primary goal of developing acronymGIN/acronym indices was
+ support for highly scalable, full-text search in
+ productnamePostgreSQL/productname and there are often situations when
+ a full-text search returns a very large set of results. Since reading