@@ -216,8 +216,8 @@ GIN indexes
216
216
JsQuery extension contains two operator classes (opclasses) for GIN which
217
217
provide different kinds of query optimization.
218
218
219
- * jsonb\_ value\_ path\_ ops
220
219
* jsonb\_ path\_ value\_ ops
220
+ * jsonb\_ value\_ path\_ ops
221
221
222
222
In each of two GIN opclasses jsonb documents are decomposed into entries. Each
223
223
entry is associated with particular value and it's path. Difference between
@@ -243,9 +243,9 @@ key "a" is presented three times. In the large branchy documents with long
243
243
keys size of naive entries representation becomes unreasonable. Both opclasses
244
244
address this issue but in a slightly different way.
245
245
246
- ### jsonb\_ value \ _ path\_ ops
246
+ ### jsonb\_ path\_ value \_ ops
247
247
248
- jsonb\_ value \ _ path\_ ops represents entry as pair of path hash and value.
248
+ jsonb\_ path\_ value \_ ops represents entry as pair of path hash and value.
249
249
Following pseudocode illustrates it.
250
250
251
251
(hash(path_item_1.path_item_2. ... .path_item_n); value)
@@ -256,9 +256,9 @@ is hashed and it is higher part of entry we need to know the full path to
256
256
the value in order to use it for search. However, once path is specified
257
257
we can use both exact and range searches very efficiently.
258
258
259
- ### jsonb\_ path \ _ value\_ ops
259
+ ### jsonb\_ value\_ path \_ ops
260
260
261
- jsonb\_ path \ _ value\_ ops represents entry as pair of value and bloom filter
261
+ jsonb\_ value\_ path \_ ops represents entry as pair of value and bloom filter
262
262
of path.
263
263
264
264
(value; bloom(path_item_1) | bloom(path_item_2) | ... | bloom(path_item_n))
0 commit comments