It is definitely true that message throughput may increase if we let the B-tree grow a bit. It removes contention between the delete process and the enqueue process.
I've actually seen this happen on the STS application (for those who've heard of it). Having a reaper/garbage collector/vacuum/re-org process is a good way to go. John On 25/01/07, Robert Greig <[EMAIL PROTECTED]> wrote:
On 25/01/07, Marnie McCormack <[EMAIL PROTECTED]> wrote: > I don't know about how BDB manages indexing (or it's equivalent) - I'm > supposing this would be key to how fast updates to growing tables would be ? BDB is essentially just a btree. We index the delivery table on message id, so the update would be to the value not the key. The update should in fact be cheaper than deletion of the row. We may also choose to create a secondary index on delete date. > Certainly backup/restore processes would be expected to lengthen - though no > way of knowing by what factor. I think (hope!) the backup and restore times will be proportional to the number of messages in the store, irrespective of whether they are delivered or pending delivery. RG
