Instead of merging shard data using make_combined_reader(), take advantage
of the fact that shard data is disjoint, and use make_joining_reader().
This removes the need to sort the partitions as they are being read.
In case of SELECT DISTINCT statments we are not intersted in clustering
keys at all. The only important information is whether partition key
exists and what's in static row (if it exists).
Signed-off-by: Paweł Dziepak <pdziepak@cloudius-systems.com>
This patch adds a "ninja clean", better than the current "ninja -t clean".
Ninja's "ninja -t clean" is a nice trick, designed to save the Makefile writer
the tedious chore of listing the targets to remove, by automatically gathering
this list. But our build system, following OSv's one, actually uses a much
cooler (and better) trick: All build files are generated in a single
subdirectory, "build/", and cleaning the build products is as simple as
"rm -rf build".
So this patch adds a target, "ninja clean", which does exactly this (rm -rf
build). "ninja clean" is not only easier to type than "ninja -t clean", it
also has one important benefit: When the ninja rules change, "ninja -t clean"
doesn't remember to delete now-defunct targets, and they stay behind. On my
build machine, "ninja -t clean" left behind almost a gigabyte of old crap.
Moreover, when the ninja file changes drastically (as it changed a few days
ago), not cleaning up everything can even cause new builds to break - e.g.,
when something was previously a file and now needs to be a directory.
Signed-off-by: Nadav Har'El <nyh@cloudius-systems.com>
Take the request processing part into the separate function and
run it in parallel for incoming requests.
Signed-off-by: Vlad Zolotarov <vladz@cloudius-systems.com>
"This patchset translates all the remaining parts of Java code needed to
support multi column restrictions. There are at least two problems left
though:
- CASSANDRA-8613 - allow something like:
SELECT * FROM table WHERE c1 = 0 AND (c2, c3) = (1, 2)
currently columns restricted by multi column restrictions need to be a
prefix of clustering key
- CASSANDRA-7281 - incorrect results if some of the columns have reversed
type
I didn't want to delay this patchset any further and fixing these issues
isn't as straighforward as just translating Java to C++."
If a user tries to configure a non-existant logger, he gets an obscure error
message:
$ scylla --logger-log-level nonexistant=info
Exiting on unhandled exception of type 'std::out_of_range': _Map_base::at
With this patch,
$ scylla --logger-log-level nonexistant=info
Exiting on unhandled exception of type 'std::runtime_error':
Unknown logger 'nonexistant'. Use --help-loggers to list available loggers.
Signed-off-by: Nadav Har'El <nyh@cloudius-systems.com>
If someone uses "--logger-log-level" with an unknown log level, e.g.,
"--logger-log-level repair=hello", the exception currently reported to the
user is:
bad lexical cast: source type value could not be interpreted as target
In a long command line, the user has no idea where this exception is coming
from. This patches catches this exception, and instead reports a runtime_error
with the text:
Unknown log level 'hello'
Which hopefully should be much more user friendly.
Signed-off-by: Nadav Har'El <nyh@cloudius-systems.com>
Current code passes the storage_proxy instance of the shard on which the
message was received instead of using the storage_proxy instance of the
shard that sent the request.
Signed-off-by: Shlomi Livne <shlomi@cloudius-systems.com>
In preparation for adding listener state to migration manager, use
sharded<> for migration manager.
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
We use storage_proxy::mutate_locally() to apply the mutations when we
receive them. mutate_locally() will ignore the mutation if the cf does not
exist. We check in the prepare phase to make sure all the cf's exist.
Thanks to the new mutation reader (storage_proxy::make_local_reader), we
can read mutations for a cf on all shard. This simplifies the sharding
handling a lot. When user of streaming creates a stream_plan on any
shard, it will send data from all shards to remote node and receive
data from all shards on remote node.
This message is printed when we are about to run the strategy code
which may not decide to compact anything. Compaction is already
properly logged in sstables::compact_sstables().
Signed-off-by: Raphael S. Carvalho <raphaelsc@cloudius-systems.com>
The sstables write path has been partially de-futurized, but now creates a
ton of threads, and yet does not exploit this as everything is serialized.
Remove those extra threads and futures and use a single thread to write
everything. If needed, we'll employ write-behind in output_stream to
increase parallelism.
Reviewed-by: Nadav Har'El <nyh@cloudius-systems.com>
Switch sharding to work on the most significant bits of the token,
rather than the least significant bits. This is more friendly to
range operations, since adjacent partitions will reside on the same shard.
Not exploited yet, except for ignoring sstables that don't belong to a
shard.
