Re: Another idea for dealing with cmin/cmax

On Oct 3, 2006, at 2:23 PM, Gregory Stark wrote:
> If the space set aside for these transaction ids is full when  
> you're inserting
> i suppose you could just go back to the FSM for another page. But I  
> don't see
> any way out when you're deleting. You have to mark xmax one way or  
> another and
> if there's no space left in the footer and you only have 4 bits in  
> the tuple
> what are you going to do?
>
> As an aside doing vacuum freeze more aggressively might reduce the  
> pressure on
> these ITL slots.
>
> But I don't see any way to guarantee a slot is available for xmax when
> deleting. We would need some sort of scheme where the space for  
> transaction
> ids is able to grow but we're already growing from both ends of the  
> page. We
> would either have to interleave transaction ids with line pointers  
> or store
> them on another special page somewhere.

Well, worst-case you could just re-do the whole page if you need to  
expand the list of transaction slots; I don't think that's a huge  
deal. What did have me baffled was how to deal with xmax though,  
since (as you mentioned), you can end up in a situation where you  
can't delete a tuple because there's no more room on the page for  
another xmax.

But I just thought of a way around that which might be better than a  
separate store for transaction info: allow for moving a tuple off the  
current page by placing a link to it's new location, similar to how  
ctid works. We probably wouldn't want to try and cram that into the  
item list, but I think we should be able to create a special version  
of a tuple header (AddressForwardingHeader) that simply states "the  
tuple has moved to this new ctid; go there".

Of course, anytime you have to follow that link you're going to pay a  
penalty, but I think this should only be needed when trying to delete  
a tuple on a page that's basically full. Theoretically, there  
shouldn't be too many people trying to hit that deleted tuple, but to  
further reduce the number of people hitting it, we could include the  
visibility info (or a pointer to it) in the AddressForwardingHeader.
--
Jim Nasby                                            jim@nasby.net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)