Horton

Re: Patch: Write Amplification Reduction Method (WARM)

Alvaro Herrera <alvherre@2ndquadrant.com>

View thread View on postgr.es
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Bruce Momjian <bruce@momjian.us>
Cc: Pavan Deolasee <pavan.deolasee@gmail.com>, Jaime Casanova <jaime.casanova@2ndquadrant.com>, Haribabu Kommi <kommi.haribabu@gmail.com>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2017-02-23T18:45:24Z
Lists: pgsql-hackers 
Bruce Momjian wrote:

> Well, let's walk through this.  Let's suppose you have three updates
> that stay on the same page and don't update any indexed columns --- that
> would produce a HOT chain of four tuples.  If you then do an update that
> changes an indexed column, prior to this patch, you get a normal update,
> and more HOT updates can be added to this.  With WARM, we can join those
> chains

With WARM, what happens is that the first three updates are HOT updates
just like currently, and the fourth one is a WARM update.

> and potentially trim the first HOT chain as those tuples become
> invisible.

That can already happen even without WARM, no?

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Commits

  1. Implement SortSupport for macaddr data type

  2. Simplify check of modified attributes in heap_update

  3. Remove direct uses of ItemPointer.{ip_blkid,ip_posid}

  4. Fix CatalogTupleInsert/Update abstraction for case of shared indstate.

  5. Provide CatalogTupleDelete() as a wrapper around simple_heap_delete().

  6. Band-aid fix for incorrect use of view options as StdRdOptions.

  7. Update visibility map in the second phase of vacuum.

  8. Avoid having two copies of the HOT-chain search logic.

  9. Postgres95 1.01 Distribution - Virgin Sources