>I would suggest to take a look at the BRIN opclass multi-minmax currently
in development.
Thank you, this does look like it could help a lot with BRIN performance in
this situation!
But again, if index performance alone was the only issue, then I would
simply accept the space overhead and switch
On Fri, Feb 12, 2021 at 6:21 PM Noah Bergbauer wrote:
>
> A btree index on the same column is 700x the size of BRIN, or 10% of
relation itself. It does not perform significantly better than BRIN. The
issue here is twofold: not only does slotting these tuples into older pages
significantly reduce t
> (My reaction to your previous thread was that it was simply a question
> of blindly insisting on using BRIN indexes for a case that they're quite
> badly adapted to. The better answer is to not use BRIN.)
Apologies, perhaps I am completely misunderstanding the motivation for BRIN?
>From the do
Noah Bergbauer writes:
> I am working on a project where I do not want Postgres to reuse free space
> in old pages (see
> https://www.postgresql.org/message-id/flat/CABjy%2BRhbFu_Hs8ZEiOzaPaJSGB9jqFF0gDU5gtwCLiurG3NLjQ%40mail.gmail.com
> for details). I found that the HEAP_INSERT_SKIP_FSM flag acc
Hello,
I am working on a project where I do not want Postgres to reuse free space
in old pages (see
https://www.postgresql.org/message-id/flat/CABjy%2BRhbFu_Hs8ZEiOzaPaJSGB9jqFF0gDU5gtwCLiurG3NLjQ%40mail.gmail.com
for details). I found that the HEAP_INSERT_SKIP_FSM flag accomplishes this.
For a lo
