Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Commit c274345

Browse files
author
Nikita Glukhov
committed
Add some literal quoting to README
1 parent 71a11a9 commit c274345

File tree

1 file changed

+17
-16
lines changed

1 file changed

+17
-16
lines changed

README.md

Lines changed: 17 additions & 16 deletions
Original file line numberDiff line numberDiff line change
@@ -223,8 +223,8 @@ GIN indexes
223223
JsQuery extension contains two operator classes (opclasses) for GIN which
224224
provide different kinds of query optimization.
225225

226-
* jsonb\_path\_value\_ops
227-
* jsonb\_value\_path\_ops
226+
* `jsonb_path_value_ops`
227+
* `jsonb_value_path_ops`
228228

229229
In each of two GIN opclasses jsonb documents are decomposed into entries. Each
230230
entry is associated with particular value and it's path. Difference between
@@ -235,11 +235,11 @@ For example, jsonb document
235235
`{"a": [{"b": "xyz", "c": true}, 10], "d": {"e": [7, false]}}`
236236
would be decomposed into following entries:
237237

238-
* "a".#."b"."xyz"
239-
* "a".#."c".true
240-
* "a".#.10
241-
* "d"."e".#.7
242-
* "d"."e".#.false
238+
* `"a".#."b"."xyz"`
239+
* `"a".#."c".true`
240+
* `"a".#.10`
241+
* `"d"."e".#.7`
242+
* `"d"."e".#.false`
243243

244244
Since JsQuery doesn't support search in particular array index, we consider
245245
all array elements to be equivalent. Thus, each array element is marked with
@@ -250,9 +250,9 @@ key "a" is presented three times. In the large branchy documents with long
250250
keys size of naive entries representation becomes unreasonable. Both opclasses
251251
address this issue but in a slightly different way.
252252

253-
### jsonb\_path\_value\_ops
253+
### `jsonb_path_value_ops`
254254

255-
jsonb\_path\_value\_ops represents entry as pair of path hash and value.
255+
`jsonb_path_value_ops` represents entry as pair of path hash and value.
256256
Following pseudocode illustrates it.
257257

258258
(hash(path_item_1.path_item_2. ... .path_item_n); value)
@@ -263,9 +263,10 @@ is hashed and it is higher part of entry we need to know the full path to
263263
the value in order to use it for search. However, once path is specified
264264
we can use both exact and range searches very efficiently.
265265

266-
### jsonb\_value\_path\_ops
267266

268-
jsonb\_value\_path\_ops represents entry as pair of value and bloom filter
267+
### `jsonb_value_path_ops`
268+
269+
`jsonb_value_path_ops` represents entry as pair of value and bloom filter
269270
of path.
270271

271272
(value; bloom(path_item_1) | bloom(path_item_2) | ... | bloom(path_item_n))
@@ -313,11 +314,11 @@ index. This decision is made by assumption that some condition types are less
313314
selective than others. Optimizer divides conditions into following selectivity
314315
class (listed by descending of selectivity).
315316

316-
1. Equality (x = c)
317-
2. Range (c1 < x < c2)
318-
3. Inequality (x > c)
319-
4. Is (x is type)
320-
5. Any (x = \*)
317+
1. Equality (`x = c`)
318+
2. Range (`c1 < x < c2`)
319+
3. Inequality (`x > c`)
320+
4. Is (`x is type`)
321+
5. Any (`x = *`)
321322

322323
Optimizer evades index evaluation of less selective conditions when possible.
323324
For example, in the `x = 1 AND y > 0` query `x = 1` is assumed to be more

0 commit comments

Comments
 (0)