Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

One reason why it's probably a good idea is because we know WARM will not effective for all use cases and it might actually cause performance regression for some of them. Even worse and as Robert fears, it might cause data loss issues. Though TBH I haven't yet seen any concrete example where it breaks so badly that it causes data loss, but that may be because the patch still hasn't received enough eye balls or outside tests. Having table level option would allow us to incrementally improve things instead of making the initial patch so large that reviewing it is a complete nightmare. May be it's already a nightmare.

It's not as if HOT would not have caused regression for some specific use cases. But I think the general benefit was so strong that we never invested time in finding and tuning for those specific cases, thus avoided some more complexity to the code. WARM's benefits are probably not the same as HOT or our standards may have changed or we probably have resources to do much more elaborate tests, which were missing 10 years back. But now that we are aware of some regressions, the choice is between spending considerable amount of time trying to handle every case vs doing it incrementally and start delivering to majority of the users, yet keeping the patch at a manageable level.

Even if we were to provide table level option, my preference would be keep it ON by default.

Thanks,

Pavan

--