Re: Patch: Write Amplification Reduction Method (WARM)
Pavan Deolasee <pavan.deolasee@gmail.com>
From: Pavan Deolasee <pavan.deolasee@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>,
Bruce Momjian <bruce@momjian.us>, 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-03-19T07:05:10Z
Lists: pgsql-hackers
On Thu, Mar 16, 2017 at 12:53 PM, Robert Haas <robertmhaas@gmail.com> wrote: > On Wed, Mar 15, 2017 at 3:44 PM, Pavan Deolasee > <pavan.deolasee@gmail.com> wrote: > > I couldn't find a better way without a lot of complex infrastructure. > Even > > though we now have ability to mark index pointers and we know that a > given > > pointer either points to the pre-WARM chain or post-WARM chain, this does > > not solve the case when an index does not receive a new entry. In that > case, > > both pre-WARM and post-WARM tuples are reachable via the same old index > > pointer. The only way we could deal with this is to mark index pointers > as > > "common", "pre-warm" and "post-warm". But that would require us to update > > the old pointer's state from "common" to "pre-warm" for the index whose > keys > > are being updated. May be it's doable, but might be more complex than the > > current approach. > > /me scratches head. > > Aren't pre-warm and post-warm just (better) names for blue and red? > > Yeah, sounds better. Just to make it clear, the current design sets the following information: HEAP_WARM_TUPLE - When a row gets WARM updated, both old and new versions of the row are marked with HEAP_WARM_TUPLE flag. This allows us to remember that a certain row was WARM-updated, even if the update later aborts and we cleanup the new version and truncate the chain. All subsequent tuple versions will carry this flag until a non-HOT updates happens, which breaks the HOT chain. HEAP_WARM_RED - After first WARM update, the new version of the tuple is marked with this flag. This flag is also carried forward to all future HOT updated tuples. So the only tuple that has HEAP_WARM_TUPLE but not HEAP_WARM_RED is the old version before the WARM update. Also, all tuples marked with HEAP_WARM_RED flag satisfies HOT property (i.e. all index key columns share the same value). Similarly, all tuples NOT marked with HEAP_WARM_RED also satisfy HOT property. I've so far called them Red and Blue chains respectively. In addition, in the current patch, the new index pointers resulted from WARM updates are marked BTREE_INDEX_RED_POINTER/HASH_INDEX_RED_POINTER I think per your suggestion we can change HEAP_WARM_RED to HEAP_WARM_TUPLE and similarly rename the index pointers to BTREE/HASH_INDEX_WARM_POINTER and replace HEAP_WARM_TUPLE with something like HEAP_WARM_UPDATED_TUPLE to signify that this or some previous version of this chain was once WARM-updated. Does that sound ok? I can change the patch accordingly. Thanks, Pavan -- Pavan Deolasee http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Commits
-
Implement SortSupport for macaddr data type
- f90d23d0c518 10.0 cited
-
Simplify check of modified attributes in heap_update
- 2fd8685e7fd9 10.0 landed
-
Remove direct uses of ItemPointer.{ip_blkid,ip_posid}
- ce96ce60ca22 10.0 landed
-
Fix CatalogTupleInsert/Update abstraction for case of shared indstate.
- aedd554f84bb 10.0 landed
-
Provide CatalogTupleDelete() as a wrapper around simple_heap_delete().
- ab02896510e2 10.0 landed
-
Band-aid fix for incorrect use of view options as StdRdOptions.
- e3e66d8a9813 10.0 cited
-
Update visibility map in the second phase of vacuum.
- fdf9e21196a6 9.3.0 cited
-
Avoid having two copies of the HOT-chain search logic.
- 4da99ea4231e 9.2.0 cited
-
Postgres95 1.01 Distribution - Virgin Sources
- d31084e9d111 7.1.1 cited