3 ms·
Since benchmarks can be misleading I want to point out that the differences between Hydra and the "tuned"[0] PostgreSQL (which are some very basic settings) are
by rubiquity 3y ago
Since benchmarks can be misleading I want to point out that the differences between Hydra and the "tuned"[0] PostgreSQL (which are some very basic settings) are a lot less convincing, with plain old PG coming ahead on quite a few: https://tinyurl.com/eju9tht2 https://tinyurl.com/eju9tht2
I also noticed quite a bit of parity between Hydra and Citus on data set size. Is Hydra a fork of Citus columnar storage?
0 - https://github.com/ClickHouse/ClickBench/blob/main/postgresql-tuned/benchmark.sh#L7-L10 https://github.com/ClickHouse/ClickBench/blob/main/postgresq...
- arp242 3y ago> plain old PG coming ahead on quite a few I found that is common among these types of databases (e.g. Citus, Timescale, etc.) which perform well under very specific conditions, and worse for many (most?) other things, sometimes significantly worse. That said, Hydra does take up ~17.5G for that benchmark and "PostgreSQL tuned" about 120G, the insert time is ~9 times faster, and "cold run" is quite a bit faster too. It's only "hot run" that shows a fairly small difference. I think it's fair to say Hydra "wins" that benchmark. > Is Hydra a fork of Citus columnar storage? Yes: "Hydra Columnar is a fork from Citus Columnar c. April, 2022".
- riku_iki 3y ago> Hydra does take up ~17.5G for that benchmark and "PostgreSQL tuned" about 120G you can run pg on compressed filesystem
- arp242 3y agoI'm sure you can, but AFAIK neither uses compression in that benchmark so it's a fair comparison. Even if filesystem compression would reduce that to 17.5G (doubtable), it won't be free in terms of CPU cycles, and no matter what it's still ~120G to load in memory, bytes to scan/update, etc.
- riku_iki 3y agomy bet is that hydra uses compression inside already, otherwise it is hard to explain where difference comes from. > it won't be free in terms of CPU cycles it can reduce IO traffic significantly, and it can be very positive trade off depending on circumstances.
- arp242 3y agoI had assumed that PostgreSQL is so much larger because it creates heaps of indexes (which is probably also why inserts are so much slower for it), but I don't really have a good way to confirm that quickly.
- riku_iki 3y agoone can choose to not create "heaps of indexes".
- arp242 3y agoAt which point your performance will drop like a brick for these types of queries – I'm pretty sure these indexes weren't added for the craic.
- riku_iki 3y agoit depends on your query obviously. In general, I did very deep benchmarking of pg, clickhouse and duckdb, and I sure didn't make stupid mistakes like this: https://news.ycombinator.com/item?id=36990831 https://news.ycombinator.com/item?id=36990831 My dataset has 50B rows and 2tb of data, and I think columnar dbs are very overhiped and I chose pg because: - pg performance is acceptable, maybe 2-5x times slower than clickhouse and duckdb on some queries if pg is configured correctly and run on compressed storage - clickhouse and duckdb start falling apart very fast because they specialized on very narrow type of queries: https://github.com/ClickHouse/ClickHouse/issues/47520 https://github.com/ClickHouse/ClickHouse/issues/47520 https://github.com/ClickHouse/ClickHouse/issues/47521 https://github.com/ClickHouse/ClickHouse/issues/47521 https://github.com/duckdb/duckdb/discussions/6696 https://github.com/duckdb/duckdb/discussions/6696
- riku_iki 3y ago> 0 - https://github.com/ClickHouse/ClickBench/blob/main/postgresq https://github.com/ClickHouse/ClickBench/blob/main/postgresq... that postgres config is very underpowered, it has only 8 workers per gather while machine has 192 vcpus.