Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

Commit e6facb1

Browse filesBrowse files
authored
Merge pull request #114 from shadforth/update-readme
Update README with small language tweaks
2 parents 919c74f + 775de3b commit e6facb1
Copy full SHA for e6facb1

File tree

1 file changed

+34
-33
lines changed
Filter options

1 file changed

+34
-33
lines changed

‎README.md

Copy file name to clipboardExpand all lines: README.md
+34-33Lines changed: 34 additions & 33 deletions
Original file line numberDiff line numberDiff line change
@@ -8,38 +8,38 @@
88

99
## Introduction
1010

11-
The **rum** module provides access method to work with `RUM` index. It is based
12-
on the `GIN` access methods code.
11+
The **rum** module provides an access method to work with a `RUM` index. It is based
12+
on the `GIN` access method's code.
1313

14-
`GIN` index allows to perform fast full text search using `tsvector` and
15-
`tsquery` types. But full text search with GIN index has several problems:
14+
A `GIN` index allows performing fast full-text search using `tsvector` and
15+
`tsquery` types. But full-text search with a GIN index has several problems:
1616

17-
- Slow ranking. It is need position information about lexems to ranking. `GIN`
18-
index doesn't store positions of lexems. So after index scan we need additional
19-
heap scan to retrieve lexems positions.
20-
- Slow phrase search with `GIN` index. This problem relates with previous
21-
problem. It is need position information to perform phrase search.
22-
- Slow ordering by timestamp. `GIN` index can't store some related information
23-
in index with lexemes. So it is necessary to perform additional heap scan.
17+
- Slow ranking. It needs positional information about lexemes to do ranking. A `GIN`
18+
index doesn't store positions of lexemes. So after index scanning, we need an
19+
additional heap scan to retrieve lexeme positions.
20+
- Slow phrase search with a `GIN` index. This problem relates to the previous
21+
problem. It needs positional information to perform phrase search.
22+
- Slow ordering by timestamp. A `GIN` index can't store some related information
23+
in the index with lexemes. So it is necessary to perform an additional heap scan.
2424

25-
`RUM` solves this problems by storing additional information in posting tree.
25+
`RUM` solves these problems by storing additional information in a posting tree.
2626
For example, positional information of lexemes or timestamps. You can get an
27-
idea of `RUM` by the following picture:
27+
idea of `RUM` with the following diagram:
2828

2929
![How RUM stores additional information](img/gin_rum.png)
3030

31-
Drawback of `RUM` is that it has slower build and insert time than `GIN`.
32-
It is because we need to store additional information besides keys and because
33-
`RUM` uses generic WAL records.
31+
A drawback of `RUM` is that it has slower build and insert times than `GIN`.
32+
This is because we need to store additional information besides keys and because
33+
`RUM` uses generic Write-Ahead Log (WAL) records.
3434

3535
## License
3636

37-
This module available under the [license](LICENSE) similar to
37+
This module is available under the [license](LICENSE) similar to
3838
[PostgreSQL](http://www.postgresql.org/about/licence/).
3939

4040
## Installation
4141

42-
Before build and install **rum** you should ensure following:
42+
Before building and installing **rum**, you should ensure following are installed:
4343

4444
* PostgreSQL version is 9.6+.
4545

@@ -62,7 +62,7 @@ Typical installation procedure may look like this:
6262
6363
## Common operators and functions
6464

65-
**rum** module provides next operators.
65+
The **rum** module provides next operators.
6666

6767
| Operator | Returns | Description
6868
| -------------------- | ------- | ----------------------------------------------
@@ -71,19 +71,19 @@ Typical installation procedure may look like this:
7171
| timestamp <=| timestamp | float8 | Returns distance only for left timestamps.
7272
| timestamp |=> timestamp | float8 | Returns distance only for right timestamps.
7373

74-
Last three operations also works for types timestamptz, int2, int4, int8, float4, float8,
74+
The last three operations also work for types timestamptz, int2, int4, int8, float4, float8,
7575
money and oid.
7676

7777
## Operator classes
7878

79-
**rum** provides next operator classes.
79+
**rum** provides the following operator classes.
8080

8181
### rum_tsvector_ops
8282

8383
For type: `tsvector`
8484

85-
This operator class stores `tsvector` lexemes with positional information. Supports
86-
ordering by `<=>` operator and prefix search. There is the example.
85+
This operator class stores `tsvector` lexemes with positional information. It supports
86+
ordering by the `<=>` operator and prefix search. See the example below.
8787

8888
Let us assume we have the table:
8989

@@ -140,8 +140,8 @@ SELECT t, a <=> to_tsquery('english', 'place | situation') AS rank
140140

141141
For type: `tsvector`
142142

143-
This operator class stores hash of `tsvector` lexemes with positional information.
144-
Supports ordering by `<=>` operator. But **doesn't** support prefix search.
143+
This operator class stores a hash of `tsvector` lexemes with positional information.
144+
It supports ordering by the `<=>` operator. It **doesn't** support prefix search.
145145

146146
### rum_TYPE_ops
147147

@@ -153,17 +153,18 @@ Supported operations: `<`, `<=`, `=`, `>=`, `>` for all types and
153153
`<=>`, `<=|` and `|=>` for int2, int4, int8, float4, float8, money, oid,
154154
timestamp and timestamptz types.
155155

156-
Supports ordering by `<=>`, `<=|` and `|=>` operators. Can be used with
156+
This operator supports ordering by the `<=>`, `<=|` and `|=>` operators. It can be used with
157157
`rum_tsvector_addon_ops`, `rum_tsvector_hash_addon_ops' and `rum_anyarray_addon_ops` operator classes.
158158

159159
### rum_tsvector_addon_ops
160160

161161
For type: `tsvector`
162162

163-
This operator class stores `tsvector` lexems with any supported by module
164-
field. There is the example.
163+
This operator class stores `tsvector` lexemes with any supported by module
164+
field. See the example below.
165165

166166
Let us assume we have the table:
167+
167168
```sql
168169
CREATE TABLE tsts (id int, t tsvector, d timestamp);
169170

@@ -202,16 +203,16 @@ SELECT id, d, d <=> '2016-05-16 14:21:25' FROM tsts WHERE t @@ 'wr&qh' ORDER BY
202203

203204
For type: `tsvector`
204205

205-
This operator class stores hash of `tsvector` lexems with any supported by module
206+
This operator class stores a hash of `tsvector` lexemes with any supported by module
206207
field.
207208

208-
**Doesn't** support prefix search.
209+
It **doesn't** support prefix search.
209210

210211
### rum_tsquery_ops
211212

212213
For type: `tsquery`
213214

214-
Stores branches of query tree in additional information. For example we have the table:
215+
It stores branches of query tree in additional information. For example, we have the table:
215216
```sql
216217
CREATE TABLE query (q tsquery, tag text);
217218

@@ -240,8 +241,8 @@ SELECT * FROM query
240241
For type: `anyarray`
241242

242243
This operator class stores `anyarray` elements with length of the array.
243-
Supports operators `&&`, `@>`, `<@`, `=`, `%` operators. Supports ordering by `<=>` operator.
244-
For example we have the table:
244+
It supports operators `&&`, `@>`, `<@`, `=`, `%` operators. It also supports ordering by `<=>` operator.
245+
For example, we have the table:
245246

246247
```sql
247248
CREATE TABLE test_array (i int2[]);

0 commit comments

Comments
0 (0)
Morty Proxy This is a proxified and sanitized view of the page, visit original site.