Re: UNDO and in-place update

On Wed, Jan 4, 2017 at 8:35 PM, Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> On Wed, Jan 4, 2017 at 4:35 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>> In this new system, I
>> think we can't remove undo entries of heap page till we clear
>> corresponding index entries. I think we need to somehow collect the
>> old values from undo corresponding to index and then scan the index
>> remove the index entry and after that corresponding undo entry can be
>> removed.
>
> Do we really need to keep undo for heap until index entry is not
> removed?
>

UNDO has to be kept till heap page is marked as all visible. This is
required to check the visibility of index. Now, I think the page can
be marked as all visible when we removed corresponding dead entries in
heap. I think the main point of discussion here is how vacuum will
clean heap and index entries in this new system. Another idea could
be that we allow undo entries to be removed (we can allow heap entry
to be removed) based on if they are visible or not and then while
traversing index we cross check in heap if the entry can be removed.
Basically, check the TID and traverse undo contents if any to verify
if the index entry can be removed. I think this sounds to be more
complicated and less efficient than what I suggested earlier.

> IIUC, we anyway need to revalidate the index key with heap
> tuple. What I am trying the say is that if we no longer needed UNDO
> for the heap page (e.g because of rollback) then we can apply the UNDO
> and remove it. I agree that there will be multiple index entries will
> be pointing to this tuple, but only one of them can pass the key
> revalidation with the heap. isn't it?
>

Yeah, but I think for that, you need to grovel through all the undo
chain if present for a tuple.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com