Just out of interest what would you say a 'higher throughput' was?
106 karma · joined May 17, 2022
https://docs.timescale.com/self-hosted/latest/install/instal...
I'd personally recommend StackGres, it's a great project.
My initial reaction is that I think one of the reasons you're seeing a hypertable being slower is almost certainly that it creates an index on the timestamp column by default. You don't have an index on your standard table which lets it go faster.
You can use create_hypertable with create_default_indexes=>false to skip creating the index, or you can just drop the index before you ingest data. You'll eventually want that index - but it's best created after ingestion in a one-shot load like this.
I'd also be interested in how the HDD you're reading data from is holding up in some of the highly parallel setups?
It's funny, we hear this more and more "we did some research and landed on Influx and ... help it's confusing".
We actually wrote an article about what we think, you can find it here: https://www.timescale.com/blog/what-influxdb-got-wrong/
As the QuestDB folks mentioned if you want a drop in replacement for Influx then they would be an option, it kinda sounds that's not what you want though - why buy into an ecosystem which isn't a good fit for you?
If you want something based on PostgreSQL, rock-solid, supports full SQL, and gives you all the benefits of a relational database, combined with all the functionality of a time-series database then give https://docs.timescale.com a look.
We have a cloud product at https://timescale.com if you're into that.
Can't wait to test them with some big data.
It’s as easy as:
CREATE EXTENSION timescaledb:
SELECT create_hypertable('table_name', 'time_column_name', chunk_time_interval=>interval '1 day'):
Easy fix - we can do a benchmark comparing TimescaleDB to pg_partman.
Longer reply: pg_partman does address many of the same developer experience items we do, but it doesn't offer things like compression or modified plans. It will perform roughly the same as declarative partitioning (because that's what it uses), and I'm guessing we will see results similar to the last large table (in the Declarative Partitioning section).