Jon Gjengset

@somehowchris I responded over in https://github.com/mit-pdos/noria/issues/179#issuecomment-962500999 — let's keep this PR for discussion of the PR :)

Given 232453f9bbd94383af312d432f5a41766f10f725, I'd particularly like @fintelia to take a look at this.

Ah, yes, this is probably because `evmap` has changed a fair amount since the latest commit on `master`, but it did so using additional `alpha` versions. I _think_ you can...

I'm not personally working on this now that I've graduated, so no, it's not something I'm looking into :)

The way to pre-populate the cache is simply to issue the relevant query. That's all you need to do, and then Noria will cache it :) As for explicitly eviction...

I agree that would be neat! Noria's current eviction model is simply to evict randomly from the largest views when memory approaches some threshold, but in a more production-oriented setting...

My guess would be not that much, at least not as medium core counts (~20). You might see some wins in read latency, but on balance the current read path...

I think `DataType::None` is the value you'd want here. And then if `DataType::None` is given to the sharding function, it would choose a random shard? Though we'd probably want to...

@ekmartin take your time! the deadline has now passed, so we are no longer in a rush. anything we can do to help?

This was raised in [a Reddit comment](https://www.reddit.com/r/rust/comments/acucrs/rust_at_speed_building_a_fast_concurrent_database/edde707/) where I also gave a rough answer. I think it's relatively hard to make Noria just work "in front of" a SQL database,...