Skip to content
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

batcheval: keep correct stats in AddSSTable without overlap #36907

Closed
wants to merge 4 commits into from

Conversation

tbg
Copy link
Member

@tbg tbg commented Apr 17, 2019

For distributed index backfill, we recently switched to allowing the stats
of the data in the SST to be blindly added to that of the range
(thus introducing ContainsEstimates=true). However, if the keyspace being
ingested into is empty (such as usually the case during IMPORT/RESTORE), it
seems a little silly to make all the consistency checks for the next 24h
twice as expensive. Probe whether the keyspace is empty and if so, don't
pretend to introduce an approximation - the stats in this case are exact.

Release note: None

tbg added 2 commits April 17, 2019 14:47
Clarify why it's OK to ingest non-atomically with applying the Raft
command.

Release note: None
Release note: None
@tbg tbg requested review from a team and dt April 17, 2019 13:37
@cockroach-teamcity
Copy link
Member

This change is Reviewable

Copy link
Member

@dt dt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Though should note that the assertion that IMPORT SSTs don't overlap is only true of distsql sorted import -- direct import will probably be the default in 19.2 and it will likely make overlapping SSTs.

//
// Note that in the event of an ill-timed crash, the data may have been
// ingested (i.e. become "visible") without the Raft command having
// marked as applied. However, the node will only serve reads once a new
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this true with follower reads?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Follower reads will see extra data, which is weird (and the data could be out-of-order with the raft log...) anyway, hard to figure what exactly a problem here would be, but closed timestamps would definitely go down the drain and everything is pretty undefined with sst ingestion anyway. I rearranged the comment and clarified.

@tbg tbg force-pushed the fix/comment-addsst branch from 664bbc7 to 0d04ad7 Compare April 17, 2019 18:17
tbg added 2 commits April 17, 2019 20:19
For distributed index backfill, we recently switched to allowing the
stats of the data in the SST to be blindly added to that of the range
(thus introducing ContainsEstimates=true). However, if the keyspace
being ingested into is empty (such as usually the case during
IMPORT/RESTORE), it seems a little silly to make all the consistency
checks for the next 24h twice as expensive. Probe whether the keyspace
is empty and if so, don't pretend to introduce an approximation - the
stats in this case are exact.

Release note: None
@tbg
Copy link
Member Author

tbg commented Oct 17, 2019

Superseded by many changes in cmd_add_sstable.go that have landed since.

@tbg tbg closed this Oct 17, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants