Earlier quoted context omitted.
Ajay, Timescale CEO and co-founder, here. It saddens me to see that we have generated so much ill will from you. It sounds like you were affected by our layoffs last year. You have every right to be upset. If you ever want to chat about this 1:1, you know how to reach me. I’d be happy to make the time. To anyone else reading this: Some of what this person has shared is true, but some of it is not true. I debated whet…
Taking responsibility for laying off a bunch of people is thin gruel. What does that mean? Nothing. They showed you loyalty, you didn't return it. The over hiring is a symptom of bad management, so taking responsibility would be to demote yourself and take a pay cut. All the executive staff should have taken one and kept more people on. It is irresponsible and cruel to overhire and then dump people. I could say more,…
pg_timeseries: Open-source time-series extension for PostgreSQL
81–84 of 84 posts
Re: pg_timeseries: Open-source time-series extension for PostgreSQL
#82Former Timescaler here. It's about time that Timescale started getting what it deserves. Sometime in early 2022, just as they raised their Series C, leadership decided that they had gotten what they wanted from the open-source community and TimescaleDB. They decided it was time to focus 100% on Timescale Cloud. Features began to become exclusive to Timescale Cloud, and the self-hosted TimescaleDB was literally treate…
Re: pg_timeseries: Open-source time-series extension for PostgreSQL
#83>You may already be asking: “why not just power the stack using TimescaleDB?” The Timescale License would restrict our use of features such as compression, incremental materialized views, and bottomless storage. With these missing, we felt that what remained would not provide an adequate basis for our customers’ time-series needs. Therefore, we decided to build our own PostgreSQL-licensed extension. Have been using t…
Re: pg_timeseries: Open-source time-series extension for PostgreSQL
#84Earlier quoted context omitted.
Looking at the comparison with Click Benchmark, they are almost pathetic in terms of performance. They cant even handle sub-second aggregation queries for 10M records. Compared that too even duckdb reading from parquet files.
Postgres is missing a proper columnstore implementation. It's a big gap and it's not easy to build. One solution could be integrating duckdb in a similar way as pgvector. You need to map duckdb storage to Postgres storage and reuse duckdb query processor. I believe it's the fastest way to get Postgres to have competitive columnstores.