On Wed, Apr 10, 2019 at 12:55 PM Heikki Linnakangas <hlinn...@iki.fi> wrote: > > On 10/04/2019 09:29, Amit Kapila wrote: > > On Tue, Apr 9, 2019 at 5:57 AM Ashwin Agrawal <aagra...@pivotal.io> wrote: > >> Row store > >> --------- > >> > >> The tuples are stored one after another, sorted by TID. For each > >> tuple, we store its 48-bit TID, a undo record pointer, and the actual > >> tuple data uncompressed. > >> > > > > Storing undo record pointer with each tuple can take quite a lot of > > space in cases where you can't compress them. > > Yeah. This does depend on compression to eliminate the unused fields > quite heavily at the moment. But you could have a flag in the header to > indicate "no undo pointer needed", and just leave it out, when it's needed. > > > Have you thought how will you implement the multi-locker scheme in > > this design? In zheap, we have used undo for the same and it is easy > > to imagine when you have separate transaction slots for each > > transaction. I am not sure how will you implement the same here. > I've been thinking that the undo record would store all the XIDs > involved. So if there are multiple lockers, the UNDO record would store > a list of XIDs. >
This will be quite tricky. Whenever a new locker arrives, you first need to fetch previous undo to see which all XIDs already have a lock on it. Not only that, it will make discarding undo's way complicated. We have considered this approach before implementing the current approach in zheap. > Alternatively, I suppose you could store multiple UNDO > pointers for the same tuple. > This will not only make the length of the tuple unnecessarily long but would make it much harder to reclaim that space once the corresponding undo is discarded. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com