Markus Dreseler

It would also be interesting to compare the throughput of the server (see https://github.com/mrks/psql_runner) with that of hyriseBenchmarkTPCH. (Ping me or @Bouncner for access rights to that repo)

So we are _even_ faster?

Compared to that other DBMS that we run the server benchmarks against ;)

When grouping the output by warning types, it doesn't look that bad anymore: ``` [:~] $ curl https://gist.githubusercontent.com/mweisgut/8044a3cbc91312f97b8a28a070908aeb/raw/e154e50d0975b33ecc163cfdeff5bb24b1f80e93/gistfile1.txt | ggrep -oP '\[[a-z/_]*\]' | sort | uniq -c % Total %...

Maybe something to discuss in the next fortnightly. How would we deal with superfluous includes, which I consider the bigger issue?

Another suggestion: *Type and *Subtype

Make sure you don't miss this part: https://github.com/hyrise/hyrise/blob/51edfa5dcc7fd34d67cc79b885474802bfa81d99/src/lib/optimizer/strategy/chunk_pruning_rule.cpp#L181

Here's what I remember from the discussion: > Keep the IndexStatistics per table, but store an additional vector of ChunkIDs for the chunk being indexed Also, remove the information about...

This sounds like a problem that we might look at some time later. In general, the optimizer should make decisions that go beyond the internal execution strategy for a single...

Do we have a list of all potential predicates that should be covered by indexes and which index supports them? This seems like something the optimizer should know.