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)
