> > 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
        for the few overflow pages.

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

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
e.g. a different header seems no easier in overflow than in heap 


---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at


Reply via email to