On 8/26/19 6:48 PM, Peter Geoghegan wrote:
Such data often consists of timestamps from a large number of low cost devices -- event data that arrives *approximately* in order. This is more or less the problem that the TimescaleDB extension targets, so it seems likely that a fair number of users care about getting it right, even if they don't know it.
This problem is not limited to IoT but to RT financial transaction ingestion as well. I found BRIN indices to work exceptionally well for that, while B-tree taking enormous amounts of space with no performance difference or win going to BRIN. The situation gets even worse when B-tree index is subjected to identical tuples which often happens when you have an avalanche of timestamps that are within less than 1ms of each other (frequent TS rounding resolution).
-- Arcadiy Ivanov arca...@gmail.com | @arcivanov | https://ivanov.biz https://github.com/arcivanov