News for hackers. Stuff that matters.
Re:Postgres Indexing: When Does BRIN Win? by aspyct on Thursday July 14, 2022 @02:19AM (#32092655)
Oh nice, I have just the tables for that! Billions of well-compacted rows with a big ol' timestamp on them. Btree indices are almost as big as the table itself...
Re:Postgres Indexing: When Does BRIN Win? by Strum355 on Thursday July 14, 2022 @06:15AM (#32094081)
Note that if you delete entries in non sequential order (aka not at the start-only or the end-only) and continue inserting, BRIN index becomes much less effective. Its very much predicated upon the concept of append-only, as postgres filling deleted rows with new rows throws off the physical layout part of how BRIN works
Re:Postgres Indexing: When Does BRIN Win? by aspyct on Thursday July 14, 2022 @07:35AM (#32094582)
I don't delete anything in those tables, however I do one update on 9/10 of the rows, at least.

I seem to remember there was a way to reorder rows in a table, maybe that could be useful.

Re:Postgres Indexing: When Does BRIN Win? by pramsey on Thursday July 14, 2022 @11:59AM (#32097750)
You can check if your data remain correlated after your updates. It's possible they do: SELECT correlation FROM pg_stats WHERE tablename = 'mytable' AND attname = 'mytimestamp';
Re:Postgres Indexing: When Does BRIN Win? by aspyct on Friday July 15, 2022 @04:04AM (#32105865)
Oh nice! I had no idea, I'll try it, thanks :)
Re:Postgres Indexing: When Does BRIN Win? by geordee on Thursday July 14, 2022 @03:58AM (#32093275)
This is similar to Zone Maps in Netezza. https://www.ibm.com/docs/en/psfa/7.2.1?topic=statistics-zone...

Incidentally, Netezza was built on Postgres engine, years back.