This addresses one of the remarks in the PR.
All format schemas are required to be in the <format_schema_path> directory.
This makes loading schema files less tedious, as the path can be omitted.
Cap'n Proto is a binary message format.
Like Protocol Buffers and Thrift (but unlike JSON or MessagePack), Cap'n Proto messages are strongly-typed and not self-describing. Due to this, it requires a schema setting to specify schema file and the root object. The schema is parsed on runtime and cached for each SQL statement.
Previously the destination columns were only computed for the first
block, so that subsequently written blocks failed to write
aggregation results to corrent columns.
By default sum(x) promotes the result type to
largest possible integral type to avoid
arithmetic overflow when summing values from
smaller data types.
This is generally desirable behaviour, but it doesn’t
work with summing merge tree, as the result is
expected to be of same type as the input.
This fixes a variant of SummingMergeTree() in which
the columns to sum are explicitly configured.
Previously columns not in that list were ignored,
instead of writing last value.
This also fixes summation of invalid maps with
with only one key column and no value columns.
Modified test to work around compaction limitation
in which a zero-value column isn’t compacted
immediately if the inputs are non-zero but the
output is zero (+1 -1).
* Log query id in executeQuery; Better type mismatch error; change format in report tool
* Better log query_id
* fix message
* Use c++11 thread_local instaed of gcc's __thread
* lock mutex before notifying waiting thread in sync insertion into distributed [#CLICKHOUSE-3379]
* Cmake: fix build without downloaded submodules (#1379)
* fix
* ZooKeeper: fixed stack smashing with tryGet()
The tryGet() operation creates a 1MB buffer on stack. This may or
may not work depending on the default stack size for threads,
whether the stack protector is enabled or not, recursion depth,
and the actual value size.
This is probably going to slow down some ZK operations, but I don't
see how else this could work reliably with the existing API.
* increased timeout for test_insertion_sync_fails_with_timeout
* Update CHANGELOG_RU.md
* Update ZooKeeper.cpp
* Fix warnings
* Fixes
* Dont strip debug info from asan, tsan and other builds except releases
* Fix asan error causd by test 00144
* Fix empty log message (#CLICKHOUSE-3378)
When using a LIMIT to reduce the number of rows
read, JSONEachRow format would always read an
extra row as it triggered a scan to seek the
EOF or beginning of the next row. This is not
an issue with physical tables, but it is
for streaming tables as an extra row is
unintentionally consumed on each read.
In the current version of Poco, unsigned long no longer aliases to
UInt64 with LP64. The size_t aliases to unsigned long with clang,
so all the uses of size_t instead of UInt64 when interacting with
Poco interfaces are gone. I replaced uses with UInt64 where it makes
sense, and added an overloaded function for readVarUInt() to support size_t.
The built-in clang doesn’t support value() for
`std::experimental::optional`. It however supports
dereference operator, which is basically the
same thing:
```
/clickhouse/dbms/src/DataStreams/NullableAdapterBlockInputStream.cpp:83:67: error: call to unavailable member function 'value':
res.insert({elem.column, elem.type, rename[i].value()});
~~~~~~~~~~^~~~~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/experimental/optional:547:17: note: candidate function has been explicitly made unavailable
value_type& value()
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/experimental/optional:539:33: note: candidate function has been explicitly made unavailable
constexpr value_type const& value() const
```
The function is rewritten to avoid allocations on every insert with
Field deserialising each array. The key type is now specialized,
so it can be accessed directly. The value type is variant type,
but only individual values are deserialised (which is cheap, since they're PODs).
The function also support summing of multiple columns by the same key.
The SummingSortedBlockInputStream uses the function in case of
Nested structure with one numeric key and many values to sum.
This replaces custom summation function implementations with an implementation
using built-in aggregation functions (sum and sumMap). The goal is to be able to
use specialized variants of aggregation functions, and to have a single
efficient implementation.
This is basically useful for testing SummingSortedBlockInputStream
against the AggregatingBlockInputStream, which are used in the
{Summing,Aggregating}MergeTree table engines respectively.
This allows sending notifications to supported
table engines when their dependencies change.
For example, a table can be notified when a
MATERIALIZED VIEW is attached to it.
This is a building block for building pipelines.
