Describe the unexpected behaviour
What is the expected result when defining a Projection in a ReplacingMergeTree table?
Projections could define a different set of keys for the ORDER BY and as we are doing a ReplacingMergeTree I guess the system when it will merge it will be lost to know which data need to be removed or not, BUT even when setting the same keys (just in a different order) the projections are never used.
If Projections do not work with ReplacingMergeTree can we throw an exception when we try to set the projection? (don't get me wrong, if we make it work is even better !! )
How to reproduce
DROP TABLE mySecondReplacingMT;
CREATE TABLE mySecondReplacingMT
(
`key` Int64,
`someCol` String,
`eventTime` DateTime
)
ENGINE = ReplacingMergeTree(eventTime)
ORDER BY (key);
INSERT INTO mySecondReplacingMT Values (1, 'first', '2020-01-01 01:01:01');
INSERT INTO mySecondReplacingMT Values (1, 'second', '2020-01-01 00:00:00');
INSERT INTO mySecondReplacingMT Values (1, 'third', '2020-01-01 02:00:00');
INSERT INTO mySecondReplacingMT Values (2, 'first', '2020-01-01 01:00:00');
INSERT INTO mySecondReplacingMT Values (2, 'second', '2020-01-01 02:00:00');
ALTER TABLE mySecondReplacingMT ADD PROJECTION someCol_proj (
SELECT
*
ORDER BY (someCol)
);
ALTER TABLE mySecondReplacingMT MATERIALIZE PROJECTION someCol_proj;
EXPLAIN indexes=1 SELECT * FROM mySecondReplacingMT FINAL WHERE someCol='first' ORDER BY someCol;
EXPLAIN indexes=1 SELECT * FROM mySecondReplacingMT FINAL WHERE key=1;
Expected behavior
Projections work with ReplacingMergeTree
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4