Carl Rosenberger:You will see the real advantage of the new BTree indexes if you:
(1) work against hard disc, not against memory
(2) have a couple of more objects in the database than 1000 or 2000 like in your last tests
(3) do single object commits
...
You are not really doing us a favour by posting your numbers and talking about "one object" if you have 12 or more indexes on a class.
Sorry again for not doing a favour. Having many objects often leads to the requirement to be able to search quickly over different fields. Due to the large amount of them - the only way is to make more indexes. That leads to slower update/insert. In any DB.
The problem with your proposal (3 items) is that having 10-20 thousands of objects on disc with single commits will lead to very low performance.
I'm quite sure that it will outperform 5.4, but still it will be very slow with flushes turned on.
Your test isn't from real life - searchable object with only 1 integer field is something so rare that it shouldn't be treated as a measurement. Probably 12 indexes on class is overkill for some applications, but if you really have a hundreds of thousands of objects and more - that could be the only option of having indexes on all searchable fields.
I will be very glad if you'll find a solution to work with flushes more efficient. Since that may really solve huge part of this bottleneck.
Best Regards. Max.