Re: Thoughts on nbtree with logical/varwidth table identifiers, v12on-disk representation - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Thoughts on nbtree with logical/varwidth table identifiers, v12on-disk representation
Date
Msg-id CAH2-Wz=J1=GeohNorpwgx9uEu6WqrVjY7DhKFRbU7UZGvESxvg@mail.gmail.com
Whole thread Raw
In response to Re: Thoughts on nbtree with logical/varwidth table identifiers, v12on-disk representation  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-hackers
On Wed, Apr 24, 2019 at 10:43 AM Peter Geoghegan <pg@bowt.ie> wrote:
> The hard part is how to do varwidth encoding for space-efficient
> partition numbers while continuing to use IndexTuple fields for heap
> TID on the leaf level, *and* also having a
> BTreeTupleGetHeapTID()-style macro to get partition number without
> walking the entire index tuple. I suppose you could make the byte at
> the end of the tuple indicate that there are in fact 31 bits total
> when its high bit is set -- otherwise it's a 7 bit integer. Something
> like that may be the way to go. The alignment rules seem to make it
> worthwhile to keep the heap TID in the tuple header; it seems
> inherently necessary to have a MAXALIGN()'d tuple header, so finding a
> way to consistently put the first MAXALIGN() quantum to good use seems
> wise.

It's even harder than that if you want to make it possible to walk the
tuple from either direction, which also seems useful. You want to be
able to jump straight to the end of the tuple to get the partition
number, while at the same time being able to access it in the usual
way, as if it was just another attribute.

Ugh, this is a mess. It would be so much easier if we had a tuple
representation that stored attribute offsets right in the header.

--
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: finding changed blocks using WAL scanning
Next
From: Alexander Korotkov
Date:
Subject: Re: jsonpath