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

[DNM] storage: factor out evaluation of BatchRequest #18796

Closed
wants to merge 4 commits into from

Conversation

tbg
Copy link
Member

@tbg tbg commented Sep 26, 2017

The first two commits are #18785.


See #18779.

This doesn't carry out all the work but does all the basic required
refactoring (mod cleanups).

I don't love that we're passing ReplicaEvalContext through an interface.
That should be avoidable and doing so should be instructive (I suspect
we'll trim some fat in the process):

Many methods roughly take the following form:

// GetMVCCStats returns the Replica's MVCCStats. func (rec
ReplicaEvalContext) GetMVCCStats() enginepb.MVCCStats {
   r := rec.repl
   r.mu.RLock()
defer r.mu.RUnlock()
return *r.mu.state.Stats, nil
}

and to define this method inside of the batcheval package, we'd have
instead

type ReplicaEvalContext {
   // ...
   state struct {
       *sync.Mutex
       *storagebase.ReplicaState
   }
}

@tbg tbg requested review from a team September 26, 2017 18:32
@cockroach-teamcity
Copy link
Member

This change is Reviewable

See cockroachdb#18779.

This doesn't carry out all the work but does all the basic required refactoring (mod cleanups).

I don't love that we're passing `ReplicaEvalContext` through an interface. That should be avoidable
and doing so should be instructive (I suspect we'll trim some fat in the process):

Many methods roughly take the following form:

```go
// GetMVCCStats returns the Replica's MVCCStats.
func (rec ReplicaEvalContext) GetMVCCStats() enginepb.MVCCStats {
    r := rec.repl
    r.mu.RLock()
	defer r.mu.RUnlock()
	return *r.mu.state.Stats, nil
}
```

and to define this method inside of the `batcheval` package, we'd have instead

```go
type ReplicaEvalContext {
    // ...
    state struct {
        *sync.Mutex
        *storagebase.ReplicaState
    }
}
```

though having to copy the mutex pointer smells fishy. Similar strategies can be used for most of the
other methods. The downside is that `ReplicaEvalContext` will wind up being a struct with lots of
pointers (i.e., perhaps a little large to sit in the hot path, though much smaller than
BatchRequest!). We could accommodate that by arranging some of these pointers that never change (for
example the `Engine` or the `AbortCache`) into a long-lived struct on `*Replica` instead.
@petermattis
Copy link
Collaborator

Very nice! I'm not in love with the name batcheval, but I don't have a better suggestion right now and the bike shedding there can wait until later.


Review status: 0 of 30 files reviewed at latest revision, all discussions resolved, some commit checks failed.


Comments from Reviewable

@tbg
Copy link
Member Author

tbg commented Oct 20, 2017

Let the bike shed begin, @petermattis. I'd prefer not having to carry out a rename once I brush this up.

I like batcheval and have no better name. @andreimatei suggested eval which I find is a bit ambiguous but could also work.

@petermattis
Copy link
Collaborator

eval feels too general. kveval? Shorter than batcheval and not ambiguous like eval.

@a-robinson
Copy link
Contributor

I like batcheval, FWIW

@petermattis
Copy link
Collaborator

I'm also ok with batcheval. I don't have a strong preference between that and kveval.

@tbg
Copy link
Member Author

tbg commented Nov 7, 2017

Superseded by #19888.

@tbg tbg closed this Nov 7, 2017
@tbg tbg deleted the eval branch November 7, 2017 21:21
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.

4 participants