ZomboDB indices fully interoperate with Postgres (auto)VACUUM facilities, and keeping ZomboDB indicies vacuumed is important for maintaining a high level of search performance.
Because ZomboDB stores row-level visibility information in its indices, ZomboDB's vacuum process is quite a bit different than standard index types like btree.
ZomboDB's approach is to:
xmin
. These represent rows where the inserting/updating transaction aborted. They can be deletedxmax
. These represent deleted rows or old versions of updated rows from a committed transaction. They can be deleted.xmax
. These represent rows where the updating/deleting transaction aborted. These rows can have their xmax
reset to null
In all cases, the evaluation of "known-to-be" means that the transaction id is older than the "oldest xmin" that Postgres determines. This means the xid's state is known to all past, present, and future transactions.
Additionally, in cases #1 and #2 ZomboDB needs to perform a "scripted delete" against Elasticsearch whereby it only deletes the doc if, in the case of #1, the doc's current xmin
matches what we expected it to be, and in the case of #2 and #3, if the doc's current xmax
matches what we expect it to be. This is because Postgres could decide to reuse those heap tuple slots between when ZomboDB's vacuum process identifies that row and when it tries to delete it.
The first thing to consider is that a VACUUM FULL
will also reindex any indicies attached to the table, including ZomboDB indices. As such, a VACUUM FULL
could take a very long time.
A normal VACUUM
will simply do the work outlined above.
A VACUUM FREEZE
will adjust xmin/xmax values on the heap but not change anything in the ZomboDB indices. This is actually okay as ZomboDB stores epoch-encoded 64bit transaction ids that aren't subject to wraparound issues that VACUUM FREEZE
is designed to prevent.
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。