Re: Patch: Write Amplification Reduction Method (WARM)

From: Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Jaime Casanova <jaime(dot)casanova(at)2ndquadrant(dot)com>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Patch: Write Amplification Reduction Method (WARM)
Date: 2017-04-04 17:48:44
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

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.


Pavan Deolasee
PostgreSQL Development, 24x7 Support, Training & Services

Attachment Content-Type Size
0001-Track-root-line-pointer-v23_v25.patch application/octet-stream 39.4 KB
0002-Free-3-bits-in-ip_posid-field-of-the-ItemPointer_v25.patch application/octet-stream 4.2 KB
0003-Main-WARM-patch_v25.patch application/octet-stream 298.7 KB
0004-Provide-control-knobs-to-decide-when-to-do-heap-_v25.patch application/octet-stream 69.9 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2017-04-04 17:52:29 Re: strange parallel query behavior after OOM crashes
Previous Message Andres Freund 2017-04-04 17:31:33 Re: logical decoding of two-phase transactions