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 [EMAIL PROTECTED]
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
