From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Arcadiy Ivanov <arcadiy(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: IoT/sensor data and B-Tree page splits |
Date: | 2019-08-27 00:18:42 |
Message-ID: | CAH2-Wzn0f=ETH=e4GEeZGyme5RjJQunZVfV9Z8nqeXib6U3Awg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Aug 26, 2019 at 4:59 PM Arcadiy Ivanov <arcadiy(at)gmail(dot)com> wrote:
> But apart from TPC-E and having to perform to it, is there any practical
> real world usefulness in trying to have a B-tree index on TS-based data
> just to have a PK on it, as opposed to having a BRIN on a TS field and
> calling it a day?
The index in question isn't an index on a timestamp. Its leading
column is an integer that is almost monotonically increasing, but not
quite.
If a BRIN index works for you, then that's probably what you should
use. I don't think that that's relevant, though. BRIN indexes have
clear disadvantages, including the fact that you have to know that
your data is amenable to BRIN indexing in order to use a BRIN index.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Ashwin Agrawal | 2019-08-27 00:33:00 | Re: Zedstore - compressed in-core columnar storage |
Previous Message | Thomas Munro | 2019-08-27 00:02:25 | Re: old_snapshot_threshold vs indexes |