On Thu, Mar 23, 2017 at 2:47 PM, Pavan Deolasee <pavan.deolasee@gmail.com> wrote: > It's quite hard to say that until we see many more benchmarks. As author of > the patch, I might have got repetitive with my benchmarks. But I've seen > over 50% improvement in TPS even without chain conversion (6 indexes on a 12 > column table test).
This seems quite mystifying. What can account for such a large performance difference in such a pessimal scenario? It seems to me that without chain conversion, WARM can only apply to each row once and therefore no sustained performance improvement should be possible -- unless rows are regularly being moved to new blocks, in which case those updates would "reset" the ability to again perform an update. However, one would hope that most updates get done within a single block, so that the row-moves-to-new-block case wouldn't happen very often.
I think you're confusing between update chains that stay within a block vs HOT/WARM chains. Even when the entire update chain stays within a block, it can be made up of multiple HOT/WARM chains and each of these chains offer ability to do one WARM update. So even without chain conversion, every alternate update will be a WARM update. So the gains are perpetual.
For example, if I take a simplistic example of a table with just one tuple and four indexes and where every update updates just one of the indexes. Assuming no WARM chain conversion this is what would happen for every update:
1. WARM update, new entry in just one index
2. Regular update, new entries in all indexes
3. WARM update, new entry in just one index
4. Regular update, new entries in all indexes
At the end of N updates (assuming all fit in the same block), one index will have N entries and rest will have N/2 entries.
Compare that against master:
1. Regular update, new entries in all indexes
2. Regular update, new entries in all indexes
3. Regular update, new entries in all indexes
4. Regular update, new entries in all indexes
At the end of N updates (assuming all fit in the same block), all indexes will have N entries. So with WARM we reduce bloats in 3 indexes. And WARM works almost in a perpetual way even without chain conversion. If you see the graph I earlier shared (attach again), without WARM chain conversion the rate of WARM updates settle down to 50%, which is not surprising given what I explained above.
