On Mon, Apr 2, 2018 at 4:27 PM, Alexander Korotkov
<a.korotkov@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