Out of curiosity, what would be required to allow deletes (but not
updates)? My thinking is that you'd want *some* way to be able to prune
data. Since you won't want to store an entire XID/CID for the delete, I
think it would be acceptable to keep a table of XID/CID values for
deletes and just store a pointer to that table in the tuple header. This
means you would be limited (perhaps severely) in the number of deletes
you could issue between vacuums, but for this instance that seems
perfectly reasonable. It might be worth using this same technique for
inserts as well. If the only inserting into the table is from some
nightly bulk process, you certainly don't need to store 4 (or is it 8)
bytes of inserting transaction data with each tuple.
Also, how does this allow for index scans without touching the heap?
AFAIK when a tuple is inserted but not committed it is already in the
index.
--
Jim C. Nasby, Database Consultant [EMAIL PROTECTED]
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
