On Mon, Apr 15, 2019 at 12:50 PM Peter Geoghegan <pg@bowt.ie> wrote:
On Mon, Apr 15, 2019 at 9:16 AM Ashwin Agrawal <aagrawal@pivotal.io> wrote: > Would like to know more specifics on this Peter. We may be having different context on hybrid row/column design.
I'm confused about how close your idea of a TID is to the traditional definition from heapam (and even zheap). If it's a purely logical identifier, then why would it have two components like a TID? Is that just a short-term convenience or something?
TID is purely logical identifier. Hence, stated in initial email that for Zedstore TID, block number and offset split carries no meaning at all. It's purely 48 bit integer entity assigned to datum of first column during insertion, based on where in BTree it gets inserted. Rest of the column datums are inserted using this assigned TID value. Just due to rest to system restrictions discussed by Heikki and Andres on table am thread poses limitations of value it can carry currently otherwise from zedstore design perspective it just integer number.
> Yes, the plan to optimize out TID space per datum, either by prefix compression or delta compression or some other trick.
It would be easier to do this if you knew for sure that the TID behaves almost the same as a bigserial column -- a purely logical monotonically increasing identifier. That's why I'm interested in what exactly you mean by TID, the stability of a TID value, etc. If a leaf page almost always stores a range covering no more than few hundred contiguous logical values, you can justify aggressively compressing the representation in the B-Tree entries. Compression would still be based on prefix compression, but the representation itself can be specialized.
Yes, it's for sure logical increasing number. With only inserts the number is monotonically increasing. With deletes and updates, insert could use the previously free'd TID values. Since TID is logical datums can be easily moved around to split or merge pages as required.