-
Notifications
You must be signed in to change notification settings - Fork 3.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sql,server: provide an approximate creation time for indexes #75753
sql,server: provide an approximate creation time for indexes #75753
Conversation
7317bd7
to
80018e9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes looking good, thanks for working on this! Just one clarification and the tests that need to be addressed
Reviewed 37 of 38 files at r1, all commit messages.
Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @ajwerner and @maryliag)
pkg/sql/schemachanger/scpb/elements.proto, line 95 at r1 (raw file):
bool unique = 3; repeated uint32 key_column_ids = 4 [(gogoproto.customname) = "KeyColumnIDs", (gogoproto.casttype) = "github.com/cockroachdb/cockroach/pkg/sql/sem/catid.ColumnID"]; repeated Direction key_column_directions = 5;
we don't rename proto because they could still being used somewhere (frontend), so we create a new one and deprecate the old. If this value is still new and not yet added to any release and being used anywhere, then it's safe to make the change.
So I just want to confirm where/if this is being used on the frontend.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @maryliag)
pkg/sql/schemachanger/scpb/elements.proto, line 95 at r1 (raw file):
Previously, maryliag (Marylia Gutierrez) wrote…
we don't rename proto because they could still being used somewhere (frontend), so we create a new one and deprecate the old. If this value is still new and not yet added to any release and being used anywhere, then it's safe to make the change.
So I just want to confirm where/if this is being used on the frontend.
I solemnly swear you don't use this protobuf in the UI anywhere. We have both never shipped this proto, it's new in 22.1, and we don't expose it via any of our status/admin routes.
755fc6b
to
6dfd7a6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You will need to rebase to deal with some conflicts, otherwise
Reviewed 1 of 38 files at r1, 32 of 32 files at r2, all commit messages.
Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @ajwerner)
@postamar any interest in a look? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: complete! 2 of 0 LGTMs obtained (waiting on @ajwerner)
This change plumbs a timestamp through to the index descriptor when it is created. The timestamp used is based on the transaction start time. The timestamp is then plumbed into the `crdb_internal.table_indexes` table and exposed as a new NULL-able TIMESTAMP column, `created_at`. Then, lastly, the timestamp is plumbed through to the status server via the `TableIndexStatsRequest`. Release note (sql change): The database now records the approximate time when an index was created it. This information is exposed via a new NULL-able TIMESTAMP column, `created_at`, on `crdb_internal.table_indexes`.
6dfd7a6
to
b732f2d
Compare
TFTR! bors r+ |
Build succeeded: |
This change plumbs a timestamp through to the index descriptor when it is
created. The timestamp used is based on the transaction start time. The
timestamp is then plumbed into the
crdb_internal.table_indexes
table andexposed as a new NULL-able TIMESTAMP column,
created_at
.Then, lastly, the timestamp is plumbed through to the status server via the
TableIndexStatsRequest
.Fixes #72626.
Release note (sql change): The database now records the approximate time when
an index was created it. This information is exposed via a new NULL-able
TIMESTAMP column,
created_at
, oncrdb_internal.table_indexes
.