Re: Patch: Write Amplification Reduction Method (WARM)

On Fri, Mar 31, 2017 at 11:15 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Thu, Mar 30, 2017 at 10:49 AM, Petr Jelinek
> <petr(dot)jelinek(at)2ndquadrant(dot)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.

Thanks,
Pavan

--
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services