- 29 11月, 2020 1 次提交
-
-
由 robot-clickhouse 提交于
-
- 13 11月, 2020 1 次提交
-
-
由 Amos Bird 提交于
-
- 10 11月, 2020 3 次提交
-
-
由 Nikolai Kochetov 提交于
-
由 Alexander Tokmakov 提交于
-
由 Nikolai Kochetov 提交于
-
- 09 11月, 2020 1 次提交
-
-
由 Nikolai Kochetov 提交于
-
- 07 11月, 2020 1 次提交
-
-
由 Alexey Milovidov 提交于
-
- 06 11月, 2020 2 次提交
- 03 11月, 2020 1 次提交
-
-
由 Nikolai Kochetov 提交于
-
- 20 10月, 2020 1 次提交
-
-
由 Nikolai Kochetov 提交于
-
- 09 10月, 2020 1 次提交
-
-
由 Nikolai Kochetov 提交于
-
- 08 10月, 2020 1 次提交
-
-
由 Amos Bird 提交于
-
- 13 9月, 2020 2 次提交
- 03 8月, 2020 3 次提交
-
-
由 Alexey Milovidov 提交于
-
由 Alexey Milovidov 提交于
-
由 Alexey Milovidov 提交于
-
- 30 7月, 2020 1 次提交
-
-
由 Anton Popov 提交于
-
- 23 7月, 2020 1 次提交
-
-
由 Artem Zuikov 提交于
-
- 21 7月, 2020 1 次提交
-
-
由 Nikolai Kochetov 提交于
-
- 12 7月, 2020 2 次提交
-
-
由 Ivan Babrou 提交于
Conditions that are outside of PK are marked as `unknown` in `KeyCondition`, so it's safe to allow them, as long as they are always combined by `AND`.
-
由 Ivan Babrou 提交于
Existing code that looks up marks that match the query has a pathological case, when most of the part does in fact match the query. The code works by recursively splitting a part into ranges and then discarding the ranges that definitely do not match the query, based on primary key. The problem is that it requires visiting every mark that matches the query, making the complexity of this sort of look up O(n). For queries that match exact range on the primary key, we can find both left and right parts of the range with O(log 2) complexity. This change implements exactly that. To engage this optimization, the query must: * Have a prefix list of the primary key. * Have only range or single set element constraints for columns. * Have only AND as a boolean operator. Consider a table with `(service, timestamp)` as the primary key. The following conditions will be optimized: * `service = 'foo'` * `service = 'foo' and timestamp >= now() - 3600` * `service in ('foo')` * `service in ('foo') and timestamp >= now() - 3600 and timestamp <= now` The following will fall back to previous lookup algorithm: * `timestamp >= now() - 3600` * `service in ('foo', 'bar') and timestamp >= now() - 3600` * `service = 'foo'` Note that the optimization won't engage when PK has a range expression followed by a point expression, since in that case the range is not continuous. Trace query logging provides the following messages types of messages, each representing a different kind of PK usage for a part: ``` Used optimized inclusion search over index for part 20200711_5710108_5710108_0 with 9 steps Used generic exclusion search over index for part 20200711_5710118_5710228_5 with 1495 steps Not using index on part 20200710_5710473_5710473_0 ``` Number of steps translates to computational complexity. Here's a comparison for before and after for a query over 24h of data: ``` Read 4562944 rows, 148.05 MiB in 45.19249672 sec., 100966 rows/sec., 3.28 MiB/sec. Read 4183040 rows, 135.78 MiB in 0.196279627 sec., 21311636 rows/sec., 691.75 MiB/sec. ``` This is especially useful for queries that read data in order and terminate early to return "last X things" matching a query. See #11564 for more thoughts on this.
-
- 10 7月, 2020 1 次提交
-
-
由 Alexey Milovidov 提交于
Avoid exception when negative or floating point constant is used in WHERE condition for indexed tables #11905
-
- 05 7月, 2020 1 次提交
-
-
由 myrrc 提交于
* Integrated CachingAllocator into MarkCache * fixed build errors * reset func hotfix * upd: Fixing build * updated submodules links * fix 2 * updating grabber allocator proto * updating lost work * updating CMake to use concepts * some other changes to get it building (integration into MarkCache) * further integration into caches * updated Async metrics, fixed some build errors * and some other errors revealing * added perfect forwarding to some functions * fix: forward template * fix: constexpr modifier * fix: FakePODAllocator missing member func * updated PODArray constructor taking alloc params * fix: PODArray overload with n restored * fix: FakePODAlloc duplicating alloc() func * added constexpr variable for alloc_tag_t * split cache values by allocators, provided updates * fix: memcpy * fix: constexpr modifier * fix: noexcept modifier * fix: alloc_tag_t for PODArray constructor * fix: PODArray copy ctor with different alloc * fix: resize() signature * updating to lastest working master * syncing with 273267 * first draft version * fix: update Searcher to case-insensitive * added ILIKE test * fixed style errors, updated test, split like and ilike, added notILike * replaced inconsistent comments * fixed show tables ilike * updated missing test cases * regenerated ya.make * Update 01355_ilike.sql Co-authored-by: Nmyrrc <me-clickhouse@myrrec.space> Co-authored-by: Nalexey-milovidov <milovidov@yandex-team.ru>
-
- 01 7月, 2020 1 次提交
-
-
由 Nicolae Vartolomei 提交于
-
- 30 6月, 2020 1 次提交
-
-
由 Nicolae Vartolomei 提交于
Possible approach for fixing #10574 The problem is that prepared sets are built correctly, it is a hash map of key -> set where key is a hash of AST and list of data types (when we a list of tuples of literals). However, when the key is built from the index to try and find if there exists a prepared set that would match it looks for data types of the primary key (see how data_types is populated) because the primary key has only one field (v in my example) it can not find the prepared set. The patch looks for any prepared indexes where data types match for the subset of fields found in primary key, we are not interested in other fields anyway for the purpose of primary key pruning.
-
- 15 6月, 2020 2 次提交
-
-
由 Alexey Milovidov 提交于
-
由 Alexey Milovidov 提交于
-
- 08 6月, 2020 2 次提交
- 02 6月, 2020 1 次提交
-
-
由 Alexander Kuzmenkov 提交于
* More LOGICAL_ERROR * Proper cloning of some Asts * Field::safeGet for user-supplied values
-
- 30 5月, 2020 1 次提交
-
-
由 Alexey Milovidov 提交于
-
- 11 5月, 2020 1 次提交
-
-
由 Andrew Onyshchuk 提交于
-
- 22 4月, 2020 1 次提交
-
-
由 Alexey Milovidov 提交于
-
- 06 4月, 2020 1 次提交
-
-
由 Anton Popov 提交于
-
- 03 4月, 2020 1 次提交
-
-
由 Ivan Lezhankin 提交于
-
- 02 4月, 2020 1 次提交
-
-
由 Ivan 提交于
* Move some code outside dbms/src folder * Fix paths
-
- 19 3月, 2020 2 次提交
-
-
由 Alexey Milovidov 提交于
-
由 Alexey Milovidov 提交于
-