opt: index accelerate chained fetch value operators

[mgartner]

opt: add test for JSON fetch val inverse

Release note: None

opt: index accelerate chained fetch value operators

Prior to #55316, the optimizer generated inverted index scans on indexed
JSON columns when queries had filters with chained fetch value
operators, for example j->'a'->'b' = '1'. The logic that made this
possible was found to create query plans not equivalent to the query, so
it was removed. This commit restores the ability to index accelerate
chained -> operators.

Fixes #55317

Release note (performance improvement): A bug fix included in 20.2.1 for
for the JSON fetch value operator, ->, resulted in chained ->
operators in query filters not being index accelerated, e.g.,
j->'a'->'b' = '1'. Chained -> are now index accelerated.

[cockroach-teamcity]

This change is 

[rytaft]

Reviewed 1 of 1 files at r1, 5 of 5 files at r2.
Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @mgartner and @RaduBerinde)

---

pkg/sql/opt/invertedidx/json_array.go, line 364 at r2 (raw file):

	// true and keys are collected and ordered by the outer-most fetch val index
	// first. For example, the expression j->'a'->'b' results in the keys
	// {"b", "a"}.

This is kind of mind-bending... but I think you've done a good job explaining with examples. I was still kind of confused for a while, though, so I think you could even go a step further in spelling it out. For example, one additional thing that might help is an addition to the function comment explaining that you'll first collect keys from the right to left, so the order of keys in the keys slice will be reversed from the order in the chain. Then you'll build up a JSON from the inside out, which will have the effect of once again reversing the order of the keys so they match the original order in the chain. That comment could show the whole transformation, e.g., j->'a'->'b' = 1 becomes j @> {"a": {"b": 1}}

---

pkg/sql/opt/invertedidx/json_array.go, line 386 at r2 (raw file):

		// variable or expression corresponding to the index column, then we
		// have found a valid list of keys to build an inverted expression.
		// an inverted

sentence fragment

[mgartner]

Reviewable status: complete! 0 of 0 LGTMs obtained (and 1 stale) (waiting on @RaduBerinde and @rytaft)

---

pkg/sql/opt/invertedidx/json_array.go, line 364 at r2 (raw file):

Previously, rytaft (Rebecca Taft) wrote…

This is kind of mind-bending... but I think you've done a good job explaining with examples. I was still kind of confused for a while, though, so I think you could even go a step further in spelling it out. For example, one additional thing that might help is an addition to the function comment explaining that you'll first collect keys from the right to left, so the order of keys in the keys slice will be reversed from the order in the chain. Then you'll build up a JSON from the inside out, which will have the effect of once again reversing the order of the keys so they match the original order in the chain. That comment could show the whole transformation, e.g., j->'a'->'b' = 1 becomes j @> {"a": {"b": 1}}

Very mind-bending. On my first attempt I was sure that I'd have to iterate over the keys backwards when building the JSON object because they are in reverse order. But the outer most fetch val index becomes the inner-most JSON object key. I've updated the comment, let me know what you think.

---

pkg/sql/opt/invertedidx/json_array.go, line 386 at r2 (raw file):

Previously, rytaft (Rebecca Taft) wrote…

sentence fragment

Done.

[rytaft]

Reviewed 2 of 5 files at r4.
Reviewable status: complete! 0 of 0 LGTMs obtained (and 1 stale) (waiting on @mgartner, @RaduBerinde, and @rytaft)

---

pkg/sql/opt/invertedidx/json_array.go, line 364 at r2 (raw file):

Previously, mgartner (Marcus Gartner) wrote…

Very mind-bending. On my first attempt I was sure that I'd have to iterate over the keys backwards when building the JSON object because they are in reverse order. But the outer most fetch val index becomes the inner-most JSON object key. I've updated the comment, let me know what you think.

I think part of what was confusing for me was that I didn't understand that the "outer-most" key in the expression tree was the right-most key in the SQL string. Maybe just adding that fact somewhere would help.

[mgartner]

Reviewable status: complete! 0 of 0 LGTMs obtained (and 1 stale) (waiting on @RaduBerinde and @rytaft)

---

pkg/sql/opt/invertedidx/json_array.go, line 364 at r2 (raw file):

Previously, rytaft (Rebecca Taft) wrote…

I think part of what was confusing for me was that I didn't understand that the "outer-most" key in the expression tree was the right-most key in the SQL string. Maybe just adding that fact somewhere would help.

Ohhh I see. Done.

[rytaft]

Reviewed 2 of 5 files at r4, 1 of 1 files at r5.
Reviewable status: complete! 0 of 0 LGTMs obtained (and 1 stale) (waiting on @mgartner and @RaduBerinde)

---

pkg/sql/opt/invertedidx/json_array.go, line 364 at r2 (raw file):

Previously, mgartner (Marcus Gartner) wrote…

Ohhh I see. Done.

Thanks!

---

pkg/sql/opt/invertedidx/json_array.go, line 374 at r5 (raw file):

	// Later on, we iterate forward through these keys to build a JSON object
	// from the inside-out with the inner-most value being the right scalar
	// expression. In the resulting JSON object, the outer-most JSON fetch value

[nit] maybe say "... inner-most value being the JSON scalar extracted above from the right ScalarExpr function argument"

[mgartner]

Reviewable status: complete! 0 of 0 LGTMs obtained (and 1 stale) (waiting on @RaduBerinde and @rytaft)

---

pkg/sql/opt/invertedidx/json_array.go, line 374 at r5 (raw file):

Previously, rytaft (Rebecca Taft) wrote…

[nit] maybe say "... inner-most value being the JSON scalar extracted above from the right ScalarExpr function argument"

Done.

[rytaft]

Reviewed 5 of 5 files at r7.
Reviewable status: complete! 0 of 0 LGTMs obtained (and 1 stale) (waiting on @RaduBerinde)

[mgartner]

TFTR!

bors r=rytaft

[craig]

Build succeeded:

• GitHub CI (Cockroach)