-
Notifications
You must be signed in to change notification settings - Fork 3.9k
sql/colfetcher: remove catalog.TableColMap
from cFetcherTableArgs
#148612
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
Conversation
It looks like your PR touches production code but doesn't add or edit any test code. Did you consider adding tests to your PR? 🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf. |
f9383ec
to
6ce8e04
Compare
6ce8e04
to
3e66f7e
Compare
Before/after of the newly added benchmark:
|
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.
Reviewed 1 of 1 files at r1, 2 of 2 files at r2, all commit messages.
Reviewable status:complete! 1 of 0 LGTMs obtained (waiting on @michae2)
-- commits
line 10 at r2:
nit: might be nice to mention explicitly that we're trading incurring an allocation for using a binary search, which seems beneficial according to the microbenchmark.
pkg/sql/colfetcher/cfetcher.go
line 1160 at r2 (raw file):
for _, f := range table.spec.FamilyDefaultColumns { if f.FamilyID == familyID { defaultColumnIdx = table.orderedColIdxMap.Get(f.DefaultColumnID)
nit: should we remove found
in favor of initializing defaultColumnIdx := -1
which will allow us to check the int being non-negative, which will also cover the case where this Get
call returns -1
?
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.
Reviewed 1 of 1 files at r1, 2 of 2 files at r2, all commit messages.
Reviewable status:complete! 2 of 0 LGTMs obtained (waiting on @mgartner)
Previously, yuzefovich (Yahor Yuzefovich) wrote…
I don't think so. The index being
That's a valid case that should not cause an internal error—it should just not unmarshal the value and continue on. However, if a family with the given |
Previously, yuzefovich (Yahor Yuzefovich) wrote…
Agreed. I should probably run some other benchmarks too to make sure there isn't a regression with a smaller number of columns. |
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 @mgartner)
pkg/sql/colfetcher/cfetcher.go
line 1160 at r2 (raw file):
Previously, mgartner (Marcus Gartner) wrote…
I don't think so. The index being
-1
maps to the previous logic inprocessValueSingle
related to the comment:// No need to unmarshal the column value. Either the column was part of // the index key or it isn't needed.
That's a valid case that should not cause an internal error—it should just not unmarshal the value and continue on. However, if a family with the given
familyID
cannot be found in the spec, that is unexpected and should result in an internal error.
Yeah, I was mostly thinking about familyID
not being found in the spec: with the current version we will return scrub.WrapError
explicitly, whereas with the new version Get
will return -1
with found=true
, so we'll call processValueSingle
with defaultColumnIdx = -1
which will effectively be no-op, so we'll swallow an error. Does this make sense?
Previously, yuzefovich (Yahor Yuzefovich) wrote…
If the family isn't in the spec, then |
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 @mgartner)
pkg/sql/colfetcher/cfetcher.go
line 1160 at r2 (raw file):
Previously, mgartner (Marcus Gartner) wrote…
If the family isn't in the spec, then
found
will remainfalse
and we'll return the scrub error.
Ah, yes, nvm, carry on.
|
Release note: None
3e66f7e
to
f2a55e4
Compare
The `catalog.TableColMap` in `cFetcherTableArgs` has been removed. Information in `IndexFetchSpec` and `cTableInfo` is used instead. Release note: None
f2a55e4
to
9a05848
Compare
TFTRs! bors r+ |
Build succeeded: |
The
catalog.TableColMap
incFetcherTableArgs
has been removed.Information in
IndexFetchSpec
andcTableInfo
is used instead.Release note: None