From: | Jeremy Finzel <finzelj(at)gmail(dot)com> |
---|---|
To: | Postgres General <pgsql-general(at)postgresql(dot)org> |
Subject: | How to use brin_summarize_range |
Date: | 2019-08-22 18:46:18 |
Message-ID: | CAMa1XUiH3hL3KGwdKGjnJdJeo2A5H1o1uhtXWBkmMqixrDCWMA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Good afternoon!
I am finding it difficult to understand how to maintain my BRIN index from
the docs. Specifically, this is the documentation on the
function brin_summarize_range which isn't clear to me:
brin_summarize_range(index regclass, blockNumber bigint) integer
- summarize the page range covering the given block, if not already
summarized
There is no information on how a user is to actually find blockNumber,
especially what blockNumber she might be interested in (like the end of the
table). On my table, my BRIN index is all of a sudden all out of whack and
I'm trying to figure out why. The planner doesn't choose it. Even if I
force a BRIN scan, it estimates way wrong, and performs terribly. I do not
have autosummarize on. I am curious if vacuum somehow invalidated
everything?
When I ran brin_summarize_new_values, it immediately returned 0. This
table has 292 million rows, and a straightforward insert-only pattern, but
we also prune data older than 1 year old. The BRIN index is on insert
time. It was working great up until just a bit ago.
Any direction on using these brin functions would be very appreciated.
Thanks,
Jeremy
From | Date | Subject | |
---|---|---|---|
Next Message | Adrian Klaver | 2019-08-22 19:22:23 | Re: How to install Postgres 12 beta with YUM |
Previous Message | Michael Lewis | 2019-08-22 18:33:30 | Support for using alias in having clause |