Re: Frequent Update Project: Design Overview of HOT Updates

> > As more UPDATEs take place these tuple chains would grow, making
> > locating the latest tuple take progressively longer.

> More generally, do we need an overflow table at all, rather
> than having these overflow tuples living in the same file as
> the root tuples? As long as there's a bit available to mark
> a tuple as being this special not-separately-indexed type,
> you don't need a special location to know what it is.

Yes, I have that same impression.

1. It doubles the IO (original page + hot page), if the new row would
have fit into the original page.

2. locking should be easier if only the original heap page is involved.

3. It makes the overflow pages really hot because all concurrent updates
compete
for the few overflow pages.

4. although at first it might seem so I see no advantage for vacuum with
overflow

5. the size reduction of heap is imho moot because you trade it for a
growing overflow
(size reduction only comes from reusing dead tuples and not
adding index tuples --> SITC)

Could you try to explain the reasoning behind separate overflow storage
?
What has been stated so far was not really conclusive to me in this
regard.
e.g. a different header seems no easier in overflow than in heap

Andreas