Description
We noticed tombstone warnings on some tables namely firstunseen, mailboxrecent and (less) messageidtable.
mailbox recent table is used to keep track of recent emails within a mailbox in order to fasten SELECT (and avoid full reads of messageidtable). The behaviour is to generally to clean up entries straight after reading them.
Hence we only have a few recent emails, but keep tumbstones for 10 days, hence selets often have to cross many tumbstone.
However this property is interesting: if we can afford some false positives, then we could aggressively decrease gc_grace_period to 0. This would cause tumbstones to be disposed of at the first compaction, significantly reducing their impact. The downside is that mis-synchronisation might lead to entries re-appearing once deleted. Which is likely acceptable on some rare occasion for mailbox recent. And such entries would eventually be cleaned up (as recent entries are removed on SELECT)
We experimented gc_grace_period = 0 on one of our production plateform and no longer see warnings for mailboxrecent table hance wanted to share this here.
Yet this approach can not be applied for other tables (firstunseen / messageidtable)
Attachments
Issue Links
- links to