Re: Heap WARM Tuples - Design Draft - Mailing list pgsql-hackers

From Claudio Freire
Subject Re: Heap WARM Tuples - Design Draft
Date
Msg-id CAGTBQpbBRpwA+=f18mxKh+E+RqmT_vW2vQWd5sWabb3rL244eg@mail.gmail.com
Whole thread Raw
In response to Re: Heap WARM Tuples - Design Draft  (Claudio Freire <klaussfreire@gmail.com>)
Responses Re: Heap WARM Tuples - Design Draft
List pgsql-hackers
On Thu, Aug 4, 2016 at 3:23 PM, Claudio Freire <klaussfreire@gmail.com> wrote:
>> That is a new HOT chain given our current code, but
>> would the new tuple addition realize it needs to create a new index
>> tuple?  The new tuple code needs to check the index's root HOT tid for a
>> non-match.
>
> I'm not proposing to change how HOT works, but adding another very
> similar mechanism on top of it called WARM.
>
> So HOT will keep working like that, HOT pruning will happen as usual,
> but we'll have the concept (immaterialized in the physical
> representation of the data, just implicit) of WARM chains. WARM chains
> would span one or several HOT chains, so they're "bigger".


Answering your question, there's no need to find the root page on index updates.

When creating the new tuple in nodeModifyTable.c, the code currently
skips updating indexes if it's using HOT.

We would add a check for WARM too. It will use WARM for index X iff both:
* ItemPointerGetBlockNumber(oldtuplectid) ==
ItemPointerGetBlockNumber(newtuplectid)* satisfies HOT for only this index X



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: handling unconvertible error messages
Next
From: Greg Stark
Date:
Subject: Re: Pgbench performance tuning?