On 4 August 2016 at 17:31, Andres Freund <andres@anarazel.de> wrote: > Hi, > > On 2016-08-04 16:29:09 +0530, Pavan Deolasee wrote: >> Indexes whose values do not change do not require new index pointers. Only >> the index whose key is being changed will need a new index entry. The new >> index entry will be set to the CTID of the root line pointer. > > That seems to require tracing all hot-chains in a page, to actually > figure out what the root line pointer of a warm-updated HOT tuple is, > provided it's HOT_UPDATED itself. Or have you found a smart way to > figure that out?
Hmm, sorry, I did think of that point and I thought I had added it to the doc.
So, yes, I agree - re-locating the root is the biggest downside to this idea. Perhaps Pavan has other thoughts?
I clearly missed this problem, so what I say now is not fully thought through. I see couple of options:
1. Most often the tuple that's being updated will be fetched by recent index scan. So we can potentially cache last (few) mappings of CTID to their root line pointers. May be we can store that in RelationData on a per relation basis.
2. I also think that most often the tuple that will be updated will have its t_ctid pointing to itself. This sounds more invasive, but can we somehow utilise the t_ctid field to store the OffsetNumber of the root line pointer? The root line pointer only exists when the tuple under consideration has HEAP_ONLY_TUPLE flag set and we know for such tuples, BlockNumber in t_ctid must be same as current block (unless HEAP_UPDATED is also set and the updating transaction eventually aborted).
We may have to fall back to a full page scan to find the root line pointer, but we can limit that for corner cases.
