> > 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 ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate