[untitaker_]

This table schema: https://github.com/timescale/tsbs/blob/bcc00137d72d889e6059e...

...seems like a quite odd way to store time-series in ClickHouse. If I understood that code correctly (and I am really not sure), they partition their data by some tag value (the first one in a list?), and sort each partition by "tags ID", while timescaledb partitions by time afaik.

Of course there will be large discrepancies if data is sorted one way in one database schema, and another way in another schema. It seems that at least their query of "ORDER BY time LIMIT 10" would greatly benefit from partitioning or sorting the table by time.

Whether that makes sense depends on your usecase. But I don't think a benchmark with completely dfferent schemas, partitioning and primary keys across databases is fair.

Another thing I noticed is that their version of ClickHouse is quite old, at least aroudn the time the test was written. The shown CREATE TABLE syntax is deprecated since a few versions and cannot be found in recent docs, only github: https://github.com/ClickHouse/ClickHouse/blob/v18.16/docs/en...

[hodgesrm]

Actually that table syntax partitions by month, which is a little non-intuitve. In modern ClickHouse SQL it would look like the following.

  CREATE TABLE tsbs_modern (
    created_date    Date     DEFAULT today(),
    created_at      DateTime DEFAULT now(),
    time            String,
    tags_id         UInt32,
    additional_tags String   DEFAULT ''
  ) ENGINE = MergeTree
  PARTITION BY toYYYYMM(created_date)
  ORDER BY (tags_id, created_at)

[untitaker_]

While the partitioning is okay, the order by is still problematic. See https://telegra.ph/No-QuestDB-is-not-Faster-than-ClickHouse-...

[hodgesrm]

That article was a good response.

[untitaker_]

Thanks, you're right. Mea culpa

[hodgesrm]

But your point that it's out of date is definitely right.