Just to clarify, I suggested fillfactor likely could *not* help because you
are indexing a column that has the value change. The idea with reducing
fillfactor is that the rows can be updated with the new versions remaining
in the same 8KB block in the file for table/row storage. If the new version
Thanks for the replies, everyone.
Gavin - I can't upgrade to a more recent version, at least not for the
foreseeable future. From what I'm reading, it's the best path forward, but
there's considerations to be made that I can't overrule.
Ninad - As I suspected about VACUUM and VACUUM FULL. Thanks
You likely need to tune your autovacuum settings such that the index bloat
reaches a steady-state and does not continue to increase. When vacuum runs,
it will remove dead (and no longer visible to any running transactions)
tuples aka row versions from each page (8KB block by default) in the file
fo
On Tue, 21 Sept 2021 at 15:59, Koen De Groote wrote:
> Greetings all,
>
> Working on postgres 11.
>
> I'm researching an index growing in size and never shrinking, and not
> being used anymore after a while.
>
> The index looks like this:
>
> "index002" btree (action_performed, should_still_perfo
On 21/09/21 22:28, Koen De Groote wrote:
Greetings all,
Working on postgres 11.
I'm researching an index growing in size and never shrinking, and not
being used anymore after a while.
The index looks like this:
|"index002" btree (action_performed, should_still_perform_action,
action_perfor
Greetings all,
Working on postgres 11.
I'm researching an index growing in size and never shrinking, and not being
used anymore after a while.
The index looks like this:
"index002" btree (action_performed, should_still_perform_action,
action_performed_at DESC) WHERE should_still_perform_action
