On Thu, Mar 30, 2017 at 10:49 AM, Petr Jelinek <petr.jelinek@2ndquadrant.com> wrote: > While reading this thread I am thinking if we could just not do WARM on > TOAST and compressed values if we know there might be regressions there. > I mean I've seen the problem WARM tries to solve mostly on timestamp or > boolean values and sometimes counters so it would still be helpful to > quite a lot of people even if we didn't do TOAST and compressed values > in v1. It's not like not doing WARM sometimes is somehow terrible, we'll > just fall back to current behavior.
Good point.
Ok. I've added logic to disable WARM update if either old or the new tuple has compressed/toasted values. The HeapDetermineModifiedColumns() has been materially changed to support this because we not only look for modified_cols, but also toasted and compressed cols and if any of the toasted or compressed cols overlap with the index attributes, we disable WARM. HOT updates which do not modify toasted/compressed attributes should still work.
I am not sure if this will be enough to address the regression that Dilip reported in his last email. AFAICS that test probably does not use toasting/compression. I hope to spend some time on that tomorrow and have a better understanding of why we see the regression.
I've also added a table-level option to turn WARM off on a given table. Right now the option can only be turned ON, but once turned ON, it can't be turned OFF. We can add that support if needed. It might be interesting to get Dilip's test running with enable_warm turned off on the table. That will at least tell us whether turning WARM off fixes the regression. Documentation changes for this reloption are missing.