This adds a Blender.recover() method that goes through and replays the log entries it finds for its base nodes.

• The log flushes are now separated by a newline, so that each JSON array can be parsed individually.
• persistence::Parameters now has an optional log_prefix that'll be used to replace soup in e.g. soup-log_0_0-0.json. Without this parallel tests would sometimes log to the same file - at the same time.
• Packets are re-created from the log entries and passed on to Domain.handle. Transactional packets are first passed through checktable.apply_batch to retrieve a timestamp. I'm not sure if the latter is completely correct though - cc @fintelia.

I've added a couple of tests, but let me know if there's anything else I should cover.

I also changed the basic example so that it calls .recover() and votes with a unique timestamp (so that the count increments each time it's run). Let me know if I should move it to another example or something though.

This implements support for auto incrementing IDs in base nodes.

• 0 values are replaced with the next auto increment value.
• Incoming non-zero values for auto increment columns are used directly, and the next auto increment value for that column will continue from there (MySQL behavior).

To make this work with shards, all auto increment columns get their values held in a DataType::ID(shard, value) type. value here is always an i64. An alternative would be to encode the shard info into the numeric value itself, i.e. through use of the first bits.

The shard index is passed through the base with on_input. Some things to consider:

• Can a base node "move" to a different shard while Soup is running? This could probably lead to collisions if that's the case. For recovery purposes I think it should still work, as long as the sharding is completely deterministic.

• How do you shard incoming rows if the key is auto incremented, and always 0? Right now this would just cause all rows to land in the first shard (see this test as an example).

• How should the user signify that they want an auto increment value for a column? Currently it's done by passing in a 0 value, but it might be better to let the value be omitted altogether (this might conflict with the default value stuff though).

Trying to build the docs from the root of this repository fails on macOS 10.15.2 with rustc 1.42.0-nightly (698fcd38f 2020-01-26)

I receive the following error:

error[E0277]: the trait bound `(): std::future::Future` is not satisfied
  --> noria/src/controller.rs:65:5
   |
65 |     type Future = impl Future<Output = Result<Self::Response, Self::Error>> + Send;
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `std::future::Future` is not implemented for `()`
   |
   = note: the return type of a function must have a statically known size

error[E0277]: the trait bound `(): std::future::Future` is not satisfied
  --> noria/src/view.rs:38:5
   |
38 | /     type Future = impl Future<
39 | |         Output = Result<multiplex::MultiplexTransport<Transport, Tagger>, tokio::io::Error>,
40 | |     >;
   | |______^ the trait `std::future::Future` is not implemented for `()`
   |
   = note: the return type of a function must have a statically known size

error[E0277]: the trait bound `(): std::future::Future` is not satisfied
  --> noria/src/table.rs:42:5
   |
42 | /     type Future = impl Future<
43 | |         Output = Result<multiplex::MultiplexTransport<Transport, Tagger>, tokio::io::Error>,
44 | |     >;
   | |______^ the trait `std::future::Future` is not implemented for `()`
   |
   = note: the return type of a function must have a statically known size

error[E0277]: the trait bound `(): std::future::Future` is not satisfied
   --> noria/src/controller.rs:179:1
    |
179 | type RpcFuture<A, R> = impl Future<Output = Result<R, failure::Error>>;
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `std::future::Future` is not implemented for `()`
    |
    = note: the return type of a function must have a statically known size

error[E0277]: the trait bound `(): std::future::Future` is not satisfied
   --> noria/src/table.rs:235:5
    |
235 |     type Future = impl Future<Output = Result<Tagged<()>, TableError>> + Send;
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `std::future::Future` is not implemented for `()`
    |
    = note: the return type of a function must have a statically known size

error[E0277]: the trait bound `(): std::future::Future` is not satisfied
   --> noria/src/view.rs:201:5
    |
201 |     type Future = impl Future<Output = Result<Vec<Datas>, ViewError>> + Send;
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `std::future::Future` is not implemented for `()`
    |
    = note: the return type of a function must have a statically known size

error: aborting due to 6 previous errors

For more information about this error, try `rustc --explain E0277`.
error: Could not document `noria`.

I am currently trying to embed noria_server into a testing project, and I can't seem to figure out what needs to go into Cargo.toml to pull in the noria_server code. Attempting to only include the noria crate in Cargo.toml throws an error stating that the noria_server crate cannot be found, while trying to pull it from GitHub directly throws a 404 error, presumably because noria_server lives in a subfolder of the noria repo. Advise on this would be much appreciated.

This runs rustfmt with --write-mode=diff on Travis, so that the build fails if there are formatting errors. It installs rustfmt from git, with the SHA 6e41100725267974fa6dcc61134d4377b676ad01.

Also shortened a few lines that were above 100 characters, to make the build pass.

This adds support for e.g. SELECT 2 * price FROM ... and SELECT price * MAX(column) FROM ... by handling nom-sql's ArithmeticExpression.

Arithmetic between different numeric data types is converted implicitly:

• BigInt + Int = BigInt
• Real + Int = Real
• Not supported: BigInt + Real (since Real's integer part is represented using an i32)

Similar to how nom-sql handles arithmetic this currently only deals with simple, non-nested, expressions, but it should definitely be possible to add support for nested expressions in the future.

I'm not completely sure if the way I've handled ArithmeticColumns in the query graph is correct (especially when it comes to re-use), but it seems to work for the tests I've written so far. The output formatting of arithmetic nodes could probably also need some tuning.

error[E0412]: cannot find type `clockid_t` in module `libc`
  --> C:\Users\xxxku\.cargo\registry\src\github.com-1ecc6299db9ec823\timekeeper-0.3.0\src\source.rs:26:31
   |
26 | fn clock_gettime(clock: libc::clockid_t) -> Result<libc::timespec, ()> {
   |                               ^^^^^^^^^ help: a type alias with a similar name exists: `clock_t`

error[E0425]: cannot find function `clock_gettime` in module `libc`
  --> C:\Users\xxxku\.cargo\registry\src\github.com-1ecc6299db9ec823\timekeeper-0.3.0\src\source.rs:33:15
   |
33 |         libc::clock_gettime(clock, &mut tp)
   |               ^^^^^^^^^^^^^ not found in `libc`
help: possible candidate is found in another module, you can import it into scope
   |
2  | use source::clock_gettime;
   |

error[E0425]: cannot find value `CLOCK_PROCESS_CPUTIME_ID` in module `libc`
  --> C:\Users\xxxku\.cargo\registry\src\github.com-1ecc6299db9ec823\timekeeper-0.3.0\src\source.rs:47:40
   |
47 |         let time = clock_gettime(libc::CLOCK_PROCESS_CPUTIME_ID).unwrap();
   |                                        ^^^^^^^^^^^^^^^^^^^^^^^^ not found in `libc`

error[E0425]: cannot find value `CLOCK_THREAD_CPUTIME_ID` in module `libc`
  --> C:\Users\xxxku\.cargo\registry\src\github.com-1ecc6299db9ec823\timekeeper-0.3.0\src\source.rs:56:40
   |
56 |         let time = clock_gettime(libc::CLOCK_THREAD_CPUTIME_ID).unwrap();
   |                                        ^^^^^^^^^^^^^^^^^^^^^^^ not found in `libc`

error: aborting due to 4 previous errors

Some errors occurred: E0412, E0425.
For more information about an error, try `rustc --explain E0412`.
error: Could not compile `timekeeper`.
warning: build failed, waiting for other jobs to finish...
error: build failed

As we move to distributed fault tolerant Soup, the terms we're using have become increasingly ambiguous and overloaded. I don't love all these names, but we should have terminology for all of the following concepts:

• domain: the collection of all shards and replicas that do computation for the same nodes in the graph.
• replica set: the part of a domain that manages a single shard.
• replica: single running instantiation of the nodes in a domain.

And for these higher level components...

• controller: component that coordinates control plane operations. Runs in the same address space as one worker, but typically interacts with more over the network.
• controller stub: component that participates in leader election. Becomes a controller if it wins.
• worker: component manages data plane operations
• worker thread pool: the collection of threads on a worker that do actual processing
• worker thread: single thread in the worker thread pool.

We should also probably have distinct DomainIndex, ReplicaSetIndex, and ReplicaIndex types as well as WorkerIndexs to identify individual processes. Depending on how they're implemented, worker indexes may have to be randomly generated to avoid collisions.

Output DOT graphs without using petgraph's stock formatter so that we can output each node's configuration using a dense, human-readable, relational-algebra-like format.

Here's what the main/web graph looks like in this new world:

I am probably doing something dumb, but I am trying to use the insert_all function, but it doesn't seem to exist.

// schema not needed for mre //
let mut votes = db.table("votes").await.unwrap();
let noria_recs: Vec<Vec<DataType>> = ...
votes.insert_all(noria_recs).await.unwrap();

gives: no method named insert_all found for struct noria::table::Table in the current scope: method not found in noria::table::Table

The definition for insert_all is

pub fn insert_all<I, V>(&mut self, i: I) -> Result<(), TableError> 
where    
I: IntoIterator<Item = V>,   
V: Into<Vec<DataType>>, 

which I believe a Vec impls IntoIterator.

I think a code snippet in the docs would be helpful

-- versions -- My Cargo.toml has noria = "0.5.0" rustc 1.45.0-nightly (47c3158c3 2020-06-04)

Sorry if I missed an obvious doc link somewhere, but I wasn't able to find comprehensive documentation on the extend of SQL support in either noria and or noria-mysql.

I'm looking to replace some part of a 1bn+ row (postgres-based) query system with Noria, since a lot of it is written in Rust and queries are already using mat views in most cases, so here goes my feature list:

• recursive and non-recursive CTE, where side-effect-free non-recursive CTE are not meant to be optimization fences (Postgres 12)
• subqueries
• UPSERT-type queries with a lot of rows (1-15 million)
• all kinds of JOINs, but SQL-default JOINs would be fine for now

While your crate does nothing wrong per se, the incoming breakage may be somewhat annoying, and you can get ahead of the breakage.

The PR that will break this crate: https://github.com/rust-lang/rust/pull/94081

The breakage: https://crater-reports.s3.amazonaws.com/pr-94081/try%23e251c42c969d6f8dbaae00e1028489c3a29f8789/reg/noria-common-0.6.0/log.txt

The fix is to move https://github.com/mit-pdos/noria/blob/465184ee4b57a2791d41b0f12fb8f71c45bae6b6/noria/src/controller.rs#L358 and https://github.com/mit-pdos/noria/blob/465184ee4b57a2791d41b0f12fb8f71c45bae6b6/noria/src/controller.rs#L179 into their own module, so that the type alias doesn't try to get inferred at the same time as the impl Trait usage in the return type.

On a positive note: https://github.com/rust-lang/rust/issues/65442 is now very much on my radar, with the PR that breaks your code this becomes actually fixable without a complex hack!

This fixes what I think is a bug in the implementation of query_through in the project operator. The implementation assumed that columns in emit were monotonically increasing, but I did not read about this as an explicit invariant. As a result the implementation would not permute columns if that was requested in emit. The following pseudo-rust illustrates the inconsistency.

let p = Project::new(emit=[0,2,1]); // <- permutation requested

let v = [1,2,3];
p.on_input([v]) // returns [1,3,2] <- correctly permuted
ancestor_state.insert(v);
p.query_through(..., states={key=1, states={..., ancestor_state }); // returns [1,2,3] <- not permuted

The new version should be as efficient as before but correctly permutes in query_through though I have not benchmarked it.

I added safety assertions for debug mode and added a test case.

The new implementation is less pretty and maybe less simple? So I added some comments explaining what it does.

Lmk if there are any questions or issues with the PR.

Although mysql does not support minus, however some subqueries may turn to minus, can these subqueries also be used to build incremental materialized views?

Hi,

I'm trying to build Noria on the following system:

OS and distribution: Lubuntu 20.10, Linux kernel 5.8.0-25-generic Rust: rustc 1.53.0-nightly (c051c5ddd 2021-04-06) Noria commit: cd639f57e8fa3fa1cdc1ca3a4c7ef3cedbe45c8c. This is the master's HEAD at the time of writing this issue.

I get the following compile errors. It seems all have to do with interfacing with the evmap crate

   Compiling noria-dataflow v0.7.0 (/home/ppf/Documents/noria/noria/server/dataflow)
error[E0603]: struct `ReadHandle` is private
   --> server/dataflow/src/backlog/multir.rs:7:19
    |
7   |     Single(evmap::ReadHandle<DataType, Vec<DataType>, i64, RandomState>),
    |                   ^^^^^^^^^^ private struct
    |
note: the struct `ReadHandle` is defined here

error[E0603]: struct `ReadHandle` is private
   --> server/dataflow/src/backlog/multir.rs:8:19
    |
8   |     Double(evmap::ReadHandle<(DataType, DataType), Vec<DataType>, i64, RandomState>),
    |                   ^^^^^^^^^^ private struct
    |
note: the struct `ReadHandle` is defined here

error[E0603]: struct `ReadHandle` is private
   --> server/dataflow/src/backlog/multir.rs:9:17
    |
9   |     Many(evmap::ReadHandle<Vec<DataType>, Vec<DataType>, i64, RandomState>),
    |                 ^^^^^^^^^^ private struct
    |
note: the struct `ReadHandle` is defined here

error[E0603]: struct `WriteHandle` is private
   --> server/dataflow/src/backlog/multiw.rs:7:19
    |
7   |     Single(evmap::WriteHandle<DataType, Vec<DataType>, i64, RandomState>),
    |                   ^^^^^^^^^^^ private struct
    |
note: the struct `WriteHandle` is defined here

error[E0603]: struct `WriteHandle` is private
   --> server/dataflow/src/backlog/multiw.rs:8:19
    |
8   |     Double(evmap::WriteHandle<(DataType, DataType), Vec<DataType>, i64, RandomState>),
    |                   ^^^^^^^^^^^ private struct
    |
note: the struct `WriteHandle` is defined here

error[E0603]: struct `WriteHandle` is private
   --> server/dataflow/src/backlog/multiw.rs:9:17
    |
9   |     Many(evmap::WriteHandle<Vec<DataType>, Vec<DataType>, i64, RandomState>),
    |                 ^^^^^^^^^^^ private struct
    |
note: the struct `WriteHandle` is defined here

warning: unnecessary trailing semicolon
   --> server/dataflow/src/ops/topk.rs:224:10
    |
224 |         };
    |          ^ help: remove this semicolon
    |
    = note: `#[warn(redundant_semicolons)]` on by default

error[E0308]: mismatched types
  --> server/dataflow/src/backlog/mod.rs:55:39
   |
55 |             (multir::Handle::$variant(r), multiw::Handle::$variant(w))
   |                                       ^ expected struct `ReadHandle`, found struct `evmap::handles::WriteHandle`
...
61 |         1 => make!(Single),
   |              ------------- in this macro invocation
   |
   = note: expected struct `ReadHandle<noria_common::DataType, Vec<noria_common::DataType>, i64, ahash::RandomState>`
              found struct `evmap::handles::WriteHandle<_, _, {integer}, ahash::RandomState>`
   = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0308]: mismatched types
  --> server/dataflow/src/backlog/mod.rs:55:68
   |
55 |             (multir::Handle::$variant(r), multiw::Handle::$variant(w))
   |                                                                    ^ expected struct `evmap::handles::WriteHandle`, found struct `ReadHandle`
...
61 |         1 => make!(Single),
   |              ------------- in this macro invocation
   |
   = note: expected struct `evmap::handles::WriteHandle<noria_common::DataType, Vec<noria_common::DataType>, i64, ahash::RandomState>`
              found struct `ReadHandle<_, _, {integer}, ahash::RandomState>`
   = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0308]: mismatched types
  --> server/dataflow/src/backlog/mod.rs:55:39
   |
55 |             (multir::Handle::$variant(r), multiw::Handle::$variant(w))
   |                                       ^ expected struct `ReadHandle`, found struct `evmap::handles::WriteHandle`
...
62 |         2 => make!(Double),
   |              ------------- in this macro invocation
   |
   = note: expected struct `ReadHandle<(noria_common::DataType, noria_common::DataType), Vec<noria_common::DataType>, i64, ahash::RandomState>`
              found struct `evmap::handles::WriteHandle<_, _, {integer}, ahash::RandomState>`
   = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0308]: mismatched types
  --> server/dataflow/src/backlog/mod.rs:55:68
   |
55 |             (multir::Handle::$variant(r), multiw::Handle::$variant(w))
   |                                                                    ^ expected struct `evmap::handles::WriteHandle`, found struct `ReadHandle`
...
62 |         2 => make!(Double),
   |              ------------- in this macro invocation
   |
   = note: expected struct `evmap::handles::WriteHandle<(noria_common::DataType, noria_common::DataType), Vec<noria_common::DataType>, i64, ahash::RandomState>`
              found struct `ReadHandle<_, _, {integer}, ahash::RandomState>`
   = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0308]: mismatched types
  --> server/dataflow/src/backlog/mod.rs:55:39
   |
55 |             (multir::Handle::$variant(r), multiw::Handle::$variant(w))
   |                                       ^ expected struct `ReadHandle`, found struct `evmap::handles::WriteHandle`
...
63 |         _ => make!(Many),
   |              ----------- in this macro invocation
   |
   = note: expected struct `ReadHandle<Vec<noria_common::DataType>, Vec<noria_common::DataType>, i64, ahash::RandomState>`
              found struct `evmap::handles::WriteHandle<_, _, {integer}, ahash::RandomState>`
   = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0308]: mismatched types
  --> server/dataflow/src/backlog/mod.rs:55:68
   |
55 |             (multir::Handle::$variant(r), multiw::Handle::$variant(w))
   |                                                                    ^ expected struct `evmap::handles::WriteHandle`, found struct `ReadHandle`
...
63 |         _ => make!(Many),
   |              ----------- in this macro invocation
   |
   = note: expected struct `evmap::handles::WriteHandle<Vec<noria_common::DataType>, Vec<noria_common::DataType>, i64, ahash::RandomState>`
              found struct `ReadHandle<_, _, {integer}, ahash::RandomState>`
   = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0599]: no method named `read` found for reference `&ReadHandle<noria_common::DataType, Vec<noria_common::DataType>, i64, ahash::RandomState>` in the current scope
  --> server/dataflow/src/backlog/multir.rs:28:29
   |
28 |                 let map = h.read()?;
   |                             ^^^^ method not found in `&ReadHandle<noria_common::DataType, Vec<noria_common::DataType>, i64, ahash::RandomState>`

error[E0599]: no method named `read` found for reference `&ReadHandle<(noria_common::DataType, noria_common::DataType), Vec<noria_common::DataType>, i64, ahash::RandomState>` in the current scope
  --> server/dataflow/src/backlog/multir.rs:57:33
   |
57 |                     let map = h.read()?;
   |                                 ^^^^ method not found in `&ReadHandle<(noria_common::DataType, noria_common::DataType), Vec<noria_common::DataType>, i64, ahash::RandomState>`

error[E0599]: no method named `read` found for reference `&ReadHandle<Vec<noria_common::DataType>, Vec<noria_common::DataType>, i64, ahash::RandomState>` in the current scope
  --> server/dataflow/src/backlog/multir.rs:64:29
   |
64 |                 let map = h.read()?;
   |                             ^^^^ method not found in `&ReadHandle<Vec<noria_common::DataType>, Vec<noria_common::DataType>, i64, ahash::RandomState>`

warning: use of deprecated associated function `evmap::handles::WriteHandle::<K, V, M, S>::empty`: Renamed to remove_entry
  --> server/dataflow/src/backlog/multiw.rs:38:19
   |
38 |                 h.empty(key_to_single(k).into_owned());
   |                   ^^^^^
   |
   = note: `#[warn(deprecated)]` on by default

warning: use of deprecated associated function `evmap::handles::WriteHandle::<K, V, M, S>::empty`: Renamed to remove_entry
  --> server/dataflow/src/backlog/multiw.rs:41:19
   |
41 |                 h.empty(key_to_double(k).into_owned());
   |                   ^^^^^

warning: use of deprecated associated function `evmap::handles::WriteHandle::<K, V, M, S>::empty`: Renamed to remove_entry
  --> server/dataflow/src/backlog/multiw.rs:44:19
   |
44 |                 h.empty(k.into_owned());
   |                   ^^^^^

error[E0599]: no method named `refresh` found for mutable reference `&mut evmap::handles::WriteHandle<noria_common::DataType, Vec<noria_common::DataType>, i64, ahash::RandomState>` in the current scope
  --> server/dataflow/src/backlog/multiw.rs:67:19
   |
67 |                 h.refresh();
   |                   ^^^^^^^ method not found in `&mut evmap::handles::WriteHandle<noria_common::DataType, Vec<noria_common::DataType>, i64, ahash::RandomState>`

error[E0599]: no method named `refresh` found for mutable reference `&mut evmap::handles::WriteHandle<(noria_common::DataType, noria_common::DataType), Vec<noria_common::DataType>, i64, ahash::RandomState>` in the current scope
  --> server/dataflow/src/backlog/multiw.rs:70:19
   |
70 |                 h.refresh();
   |                   ^^^^^^^ method not found in `&mut evmap::handles::WriteHandle<(noria_common::DataType, noria_common::DataType), Vec<noria_common::DataType>, i64, ahash::RandomState>`

error[E0599]: no method named `refresh` found for mutable reference `&mut evmap::handles::WriteHandle<Vec<noria_common::DataType>, Vec<noria_common::DataType>, i64, ahash::RandomState>` in the current scope
  --> server/dataflow/src/backlog/multiw.rs:73:19
   |
73 |                 h.refresh();
   |                   ^^^^^^^ method not found in `&mut evmap::handles::WriteHandle<Vec<noria_common::DataType>, Vec<noria_common::DataType>, i64, ahash::RandomState>`

error[E0599]: no method named `read` found for reference `&evmap::handles::WriteHandle<noria_common::DataType, Vec<noria_common::DataType>, i64, ahash::RandomState>` in the current scope
  --> server/dataflow/src/backlog/multiw.rs:85:29
   |
85 |                 let map = h.read()?;
   |                             ^^^^ method not found in `&evmap::handles::WriteHandle<noria_common::DataType, Vec<noria_common::DataType>, i64, ahash::RandomState>`

error[E0599]: no method named `read` found for reference `&evmap::handles::WriteHandle<(noria_common::DataType, noria_common::DataType), Vec<noria_common::DataType>, i64, ahash::RandomState>` in the current scope
   --> server/dataflow/src/backlog/multiw.rs:114:33
    |
114 |                     let map = h.read()?;
    |                                 ^^^^ method not found in `&evmap::handles::WriteHandle<(noria_common::DataType, noria_common::DataType), Vec<noria_common::DataType>, i64, ahash::RandomState>`

error[E0599]: no method named `read` found for reference `&evmap::handles::WriteHandle<Vec<noria_common::DataType>, Vec<noria_common::DataType>, i64, ahash::RandomState>` in the current scope
   --> server/dataflow/src/backlog/multiw.rs:121:29
    |
121 |                 let map = h.read()?;
    |                             ^^^^ method not found in `&evmap::handles::WriteHandle<Vec<noria_common::DataType>, Vec<noria_common::DataType>, i64, ahash::RandomState>`

Hi,

I have a question as to whether Noria's performance would benefit from:

1. io-uring ?

2. from the rust crate Glommio (a thread per core crate - https://www.datadoghq.com/blog/engineering/introducing-glommio/). I think the author wrote another blog about API performance and io_uring (https://itnext.io/modern-storage-is-plenty-fast-it-is-the-apis-that-are-bad-6a68319fbc1a)

3. As well as from Upmem (https://www.upmem.com/) which seems to have the most benefit (index searches) potential and smallest code change required to enable (index searches) it according to their site.

I understand the answer might be 'if you need that much performance then you should be able to afford to buy more cores rather than creating technical complexity' but some of the items above might only benefit incoming API calls from source and not Noria itself, so just want to understand at a simplistic level / answer if these would or wouldnt benefit Noria'S performance.

Thanks in advance!