sql: support ALTER INDEX … VISIBILITY ... #87301
Conversation
|
This change is |
|
|
rytaft
force-pushed
the
add-alter
branch
2 times, most recently
from
da484d2
to
589012a
Compare
rytaft
changed the title
rytaft
force-pushed
the
add-alter
branch
8 times, most recently
from
609bf42
to
79a844c
Compare
There was a problem hiding this comment.
I'm reviving this PR too. I've made a few tweaks to @wenyihu6's original commit, but not many! The first commit is #101334.
Reviewable status:
complete! 0 of 0 LGTMs obtained (waiting on @mgartner and @rharding6373)
There was a problem hiding this comment.
Reviewable status:
pkg/sql/parser/sql.y line 2398 at r14 (raw file):
return 1 } invisibilityConst := 1.0 - visibilityConst
nit: I still don't understand why we don't store this internally as visibility instead of invisibility. It seems like the 1.0 - [some visibility-related var] calculations are unnecessary. I don't feel super strongly about consistently naming everything as visibility or visible, though, as I'm sure there's a reason why we use invisibility.
There was a problem hiding this comment.
TFTR!
Reviewable status:
pkg/sql/parser/sql.y line 2398 at r14 (raw file):
Previously, rharding6373 (Rachael Harding) wrote…
nit: I still don't understand why we don't store this internally as
visibilityinstead ofinvisibility. It seems like the1.0 - [some visibility-related var]calculations are unnecessary. I don't feel super strongly about consistently naming everything asvisibilityorvisible, though, as I'm sure there's a reason why we useinvisibility.
Same comment as the other PR -- the user-facing feature is described as "visibility" (since that's more intuitive), but in the codebase we use "invisibility" for the most part since we want the default to be that all indexes are visible, and therefore have invisibility=0. I think it's easier to have the default match the go default, but let me know if you think it's too confusing.
There was a problem hiding this comment.
Reviewable status:
pkg/sql/parser/sql.y line 2398 at r14 (raw file):
Previously, rytaft (Rebecca Taft) wrote…
Same comment as the other PR -- the user-facing feature is described as "visibility" (since that's more intuitive), but in the codebase we use "invisibility" for the most part since we want the default to be that all indexes are visible, and therefore have invisibility=0. I think it's easier to have the default match the go default, but let me know if you think it's too confusing.
Ok, let's keep as is.
This commit adds support to `ALTER INDEX ... VISIBILITY ...`. `Visibility` is currently not supported with `CREATE INDEX` or `CREATE TABLE`. Users would need to create the index as it is fully not visible or fully visible first. And they can change the index visibility to any float [0.0, 1.0] using `ALTER INDEX ... VISIBILITY ...` Invisibility specifies the invisibility of an index to the optimizer and can be any float64 between [0.0, 1.0]. An index with invisibility 0.0 means that the index is visible. An index with invisibility 1.0 means that the index is fully not visible. By default, an index should be visible or invisibility 0.0. An index with invisibility 1.0 is ignored by the optimizer unless it is used for constraint check or is explicitly selected with index hinting. An index with invisibility between (0.0, 1.0) would be made fully not visible to a corresponding fraction of the queries. By convention, we will refer any indexes with invisibility == 0.0 as visible, any indexes with invisibility == 1.0 as fully not visible, and any indexes with index visibility in-between as partially not visible. Informs cockroachdb#82363 Release note (sql change): `ALTER INDEX ... VISIBILITY ...` is now supported. It can change an index visibility to any visibility within [0.0, 1.0]. Visibility 0.0 means the index is not visible to the optimizer, while visibility 1.0 means the index is fully visible. A value in the range (0.0, 1.0) means the index will be visibile to the corresponding fraction of queries. Co-authored-by: Rebecca Taft <[email protected]>
|
bors r+ |
|
Build succeeded: |
This commit adds support for CREATE INDEX ... VISIBILITY ... as well as CREATE TABLE ... (... INDEX (...) VISIBILITY ...). This allows users to set the index visibility to any float [0.0, 1.0] upon creation of the index. ALTER INDEX ... VISIBILITY ... was previously supported in cockroachdb#87301. Informs cockroachdb#82363 Release note (sql change): CREATE INDEX ... VISIBILITY ... as well as CREATE TABLE ... (... INDEX (...) VISIBILITY ...) are now supported. This allows a user to set the index visibility to any visibility within [0.0, 1.0]. Visibility 0.0 means the index is not visible to the optimizer, while visibility 1.0 means the index is fully visible. A value in the range (0.0, 1.0) means the index will be visibile to the corresponding fraction of queries.
101812: sql: support setting index visibility in CREATE INDEX and CREATE TABLE r=rytaft a=rytaft This commit adds support for `CREATE INDEX ... VISIBILITY ...` as well as `CREATE TABLE ... (... INDEX (...) VISIBILITY ...)`. This allows users to set the index visibility to any float [0.0, 1.0] upon creation of the index. `ALTER INDEX ... VISIBILITY ...` was previously supported in #87301. Informs #82363 Release note (sql change): `CREATE INDEX ... VISIBILITY ...` as well as `CREATE TABLE ... (... INDEX (...) VISIBILITY ...)` are now supported. This allows a user to set the index visibility to any visibility within [0.0, 1.0]. Visibility 0.0 means the index is not visible to the optimizer, while visibility 1.0 means the index is fully visible. A value in the range (0.0, 1.0) means the index will be visibile to the corresponding fraction of queries. Co-authored-by: Rebecca Taft <[email protected]>
This commit adds support to
ALTER INDEX ... VISIBILITY ....Visibilityiscurrently not supported with
CREATE INDEXorCREATE TABLE. Users would needto create the index as it is fully not visible or fully visible first. And they
can change the index visibility to any float [0.0, 1.0] using
ALTER INDEX ... VISIBILITY ....Invisibility specifies the invisibility of an index to the
optimizer and can be any float64 between [0.0, 1.0]. An index with invisibility
0.0 means that the index is visible. An index with invisibility 1.0 means that
the index is fully not visible. By default, an index should be visible or
invisibility 0.0. An index with invisibility 1.0 is ignored by the optimizer
unless it is used for constraint check or is explicitly selected with index
hinting. An index with invisibility between (0.0, 1.0) would be made fully not
visible to a corresponding fraction of the queries. By convention, we will
refer any indexes with invisibility == 0.0 as visible, any indexes with
invisibility == 1.0 as fully not visible, and any indexes with index visibility
in-between as partially not visible.
Informs #82363
Release note (sql change):
ALTER INDEX ... VISIBILITY ...is now supported.It can change an index visibility to any visibility within [0.0, 1.0].
Visibility 0.0 means the index is not visible to the optimizer, while
visibility 1.0 means the index is fully visible. A value in the range
(0.0, 1.0) means the index will be visibile to the corresponding fraction of
queries.