On Mon, Apr 2, 2018 at 4:27 PM, Alexander Korotkov <a.korot...@postgrespro.ru> wrote: > I thought abut that another time and I decided that it would be safer > to use 13th bit in index tuple flags. There are already attempt to > use whole 6 bytes of tid for not heap pointer information [1]. Thus, it > would be safe to use 13th bit for indicating alternative offset meaning > in pivot tuples, because it wouldn't block further work. Revised patchset > in the attachment implements it.
This is definitely not the only time someone has talked about this 13th bit -- it's quite coveted. It also came up with UPSERT, and with WARM. That's just the cases that I can personally remember. I'm glad that you found a way to make this work, that will keep things flexible for future patches, and make testing easier. I think that we can find a flexible representation that makes almost everyone happy. > I don't know. We still need an offset number to check expected number > of attributes. Passing index tuple as separate attribute would be > redundant and open door for extra possible errors. You're right. I must have been tired when I wrote that. :-) >> Do you store an attribute number in the "minus infinity" item (the >> leftmost one of internal pages)? I guess that that should be zero, >> because it's totally truncated. > > > Yes, I store zero number of attributes in "minus infinity" item. See this > part of the patch. > However, note that I've to store (number_of_attributes + 1) in the offset > in order to correctly store zero number of attributes. Otherwise, assertion > is faised in ItemPointerIsValid() macro. Makes sense. > Yes. But that depends on how difficulty to adopt patch to big picture > correlate with difficulty, which non-adopted patch makes to that big > picture. My point was that second difficulty isn't high. But we can be > satisfied with implementation in the attached patchset (probably some > small enhancements are still required), then the first difficulty isn't high > too. I think it's possible. I didn't have time to look at this properly today, but I will try to do so tomorrow. Thanks -- Peter Geoghegan
