Re: Heap WARM Tuples - Design Draft

On Thu, Aug 4, 2016 at 02:35:32PM -0300, Claudio Freire wrote:
> > Vacuum will need to be taught not to break the invariant, but I
> > believe this is viable and efficient.
>
>
> And I didn't mention the invariant.
>
> The invariant would be that all WARM chains:
>
> * contain entire HOT chains (ie: no item pointers pointing to the
> middle of a HOT chain)

You mean no _index_ item pointers, right?

> * start at the item pointer, and end when the t_ctid of the heap
> tuple either points to another page, or a tuple with a different index
> key

Uh, there is only one visible tuple in a HOT chain, so I don't see the
different index key as being a significant check. That is, I think we
should check the visibility first, as we do now, and then, for the
only-visible tuple, check the key. I don't see a value in (expensive)
checking the key of an invisible tuple in hopes of stoping the HOT chain
traversal.

Also, what happens when a tuple chain goes off-page, then returns to the
original page? 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.

> This is maintained by:
>
> * No item pointer will be created for row versions whose immediately
> previous version is already on the index with the same key

You really only have the ctid HOT head stored in the index, not the
immediate ctid.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +