3 ms·
(TimescaleDB engineer) Really curious about finding out more about your reservations about the updated schema. All criticisms welcome.
by cevian 6y ago
(TimescaleDB engineer) Really curious about finding out more about your reservations about the updated schema. All criticisms welcome.
- themgt 6y agoThanks, as I say our use case may be too odd to be worth supporting, but effectively we're trying to add a basic metrics (prom/ad-hoc) feature to an existing product (using Postgres) with an existing sort of opinionated "ORM"/toolkit for inserting/querying data. Because of that and the small scale required, the choice of table-per-metric would be a tough fit and I think a single table with JSONB and maybe some partial indexes is going to work a lot better for us. It would just be nice if we could somehow code in our schema mapping and use the supported extension, but I get it may be too baked-into the implementation. Anyway, overall we're quite happy with TimescaleDB!
- cevian 6y agoI see, that makes a whole lot of sense. This is an interesting use-case. It actually may be possible to use some of the aggregates provided by the extension even with a different schema. If you are interested in exploring further, my username on slack is `mat` and my email is the same @timescale.com