On Wed, Nov 23, 2016 at 12:27 AM, Peter Geoghegan <p...@heroku.com> wrote: > On Mon, Nov 21, 2016 at 5:15 PM, Claudio Freire <klaussfre...@gmail.com> > wrote: >>> There are a couple >>> of tricky issues with that that you'd have to look out for, like >>> making sure that the high key continues to hold a real TID, which at a >>> glance looks like something that just happens already. I'm not sure >>> that we preserve the item pointer TID in all cases, since the current >>> assumption is that a high key's TID is just filler -- maybe we can >>> lose that at some point. >> >> I thought long about that, and inner pages don't need a real TID in >> their keys, as those keys only specify key space cutoff points and not >> real tids, and high tids in leaf pages are always real. > > Not if there are duplicates in the inner pages. Then, you have to add > in the TID, and separate the key space, to guide insertions to the > right leaf page directly (particularly for non-HOT UPDATEs). That's > what I'm mostly interested in investigating, here.
My point was that the TID doesn't have to point to an actual tuple. It's more of a keyspace thing, so it doesn't need to match real tuples, it can just divide the keyspace with an arbitrary cutoff, and should be cheapter to maintain without that requirement. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
