[welder]

Funny timing... just installed 1.0 rc1 this week. Dual-writing and experimenting reading from TimescaleDB in prod currently.

So far it's been perfect... besides a small config issue[1] causing a crash that should have been detected when Postgres starts up, TimescaleDB gives me reliability and durability of Postgres without having to manually create partition tables.

What will happen when Postgres supports auto creating partition tables for declarative partitioning[2]? Will TimescaleDB still be necessary?

Feature request 1: when all rows of a chunk/partition table are deleted can that chunk be automatically dropped instead of having to manually run drop_chunks[3]?

Feature request 2: for the getting started docs, add an option to install with https://nixos.org

[1]: https://github.com/timescale/timescaledb/issues/733

[2]: https://www.postgresql.org/docs/11/static/ddl-partitioning.h...

[3]: https://docs.timescale.com/v1.0/api#drop_chunks

[cevian]

Thanks for trying out TimescaleDB. Glad you're having a good experience. :)

We think that declarative partitioning is a great step forward for Postgres partitioning. That said the process is still quite manual (including in PG11) -- unless I am mistaken, auto-creating partitioned tables is not in PG11, but perhaps may get released with PG12 at the end of 2019.

But even with auto-creating partitioned tables, TimescaleDB is still necessary for a few reasons:

- Support for multiple time-based query optimization in the planner

- More efficient handling of both queries and inserts when there are many partitions,

- Time-based analytical function like time_bucket,

- Support for changing partition sizes, etc.

We are also working on many new features, optimizations, and capabilities slated for the next year which will improve time-series workloads in PostgreSQL even more.

[akulkarni]

Also thank you for the feature requests. Would you mind creating Github [1] issues so they are easier to track and discuss?

[1] https://github.com/timescale/timescaledb