Thread: When to REINDEX a serial key?
Server: RDS Postgresql 12.5
Client: Vanilla Postgresql 12.5
Like most systems, we have lots of tables indexed on sequences. Thus, all new keys are inserted into the "lower right hand corner" of the b-tree.
The legacy RDBMS which I used to manage has a tool for analyzing (not in the Postgresql meaning of the word) an index, and displaying a histogram of how many layers deep various parts of an index are. Using that histogram, you can tell whether or not an index needs to be rebuilt.
How does one get the same effect in Postgresql?
Client: Vanilla Postgresql 12.5
Like most systems, we have lots of tables indexed on sequences. Thus, all new keys are inserted into the "lower right hand corner" of the b-tree.
The legacy RDBMS which I used to manage has a tool for analyzing (not in the Postgresql meaning of the word) an index, and displaying a histogram of how many layers deep various parts of an index are. Using that histogram, you can tell whether or not an index needs to be rebuilt.
How does one get the same effect in Postgresql?
--
Angular momentum makes the world go 'round.
Angular momentum makes the world go 'round.
On Tue, 6 Jul 2021 at 21:35, Ron <ronljohnsonjr@gmail.com> wrote: > The legacy RDBMS which I used to manage has a tool for analyzing (not in the Postgresql meaning of the word) an index,and displaying a histogram of how many layers deep various parts of an index are. Using that histogram, you can tellwhether or not an index needs to be rebuilt. > > How does one get the same effect in Postgresql? There are a few suggestions in https://wiki.postgresql.org/wiki/Show_database_bloat David
On 7/6/21 4:52 AM, David Rowley wrote: > On Tue, 6 Jul 2021 at 21:35, Ron <ronljohnsonjr@gmail.com> wrote: >> The legacy RDBMS which I used to manage has a tool for analyzing (not in the Postgresql meaning of the word) an index,and displaying a histogram of how many layers deep various parts of an index are. Using that histogram, you can tellwhether or not an index needs to be rebuilt. >> >> How does one get the same effect in Postgresql? > There are a few suggestions in > https://wiki.postgresql.org/wiki/Show_database_bloat How does bloat relate to a lopsided b-tree? -- Angular momentum makes the world go 'round.
On 06.07.21 14:19, Ron wrote: > On 7/6/21 4:52 AM, David Rowley wrote: >> On Tue, 6 Jul 2021 at 21:35, Ron <ronljohnsonjr@gmail.com> wrote: >>> The legacy RDBMS which I used to manage has a tool for analyzing (not >>> in the Postgresql meaning of the word) an index, and displaying a >>> histogram of how many layers deep various parts of an index are. >>> Using that histogram, you can tell whether or not an index needs to >>> be rebuilt. >>> >>> How does one get the same effect in Postgresql? >> There are a few suggestions in >> https://wiki.postgresql.org/wiki/Show_database_bloat > > How does bloat relate to a lopsided b-tree? There is no such thing as a lopsided B-tree, because a B-tree is by definition self-balancing. Perhaps that answers your original question. Bloat is generally something people are concerned about when they think about reindexing their indexes. But append-only workloads, such as what you describe, normally don't generate bloat.
> > There is no such thing as a lopsided B-tree, because a B-tree is by definition self-balancing. Perhaps that answers youroriginal question. > You do incur the cost of rebalancing often and the cost/frequency/extent is related to fill factor. > >