On Thu, Jun 14, 2018 at 5:43 AM, Alexander Korotkov
<a.korotkov@postgrespro.ru> wrote:
> Could you, please, clarify what do you mean by "fan-in"? As I
> understood, higher "fan-in" means more children on single non-leaf
> page, and in turn "better branching". Is my understanding correct?
Yes, your understanding is correct.
> If my understanding is correct, then making leaf level truly unique
> without suffix truncation will kill fan-in, because additional heap
> TID attribute will increase pivot tuple size.
You're right that that's theoretically possible. However, in practice
we can almost always truncate away the heap TID attribute from pivot
tuples. We only need the heap TID attribute when there is no other
distinguishing attribute.
> However, that doesn't
> look like inevitable shortcoming, because we could store heap TID in
> t_tid of pivot index tuples.
But the offset doesn't have enough space for an entire TID.
> So, my idea that it's not necessary to couple suffix truncation with
> making leaf tuples unique.
It seems like by far the simplest way. I don't really care about
suffix truncation, though. I care about making the leaf tuples unique.
Suffix truncation can help.
> Regarding just making leaf tuples unique,
> I understand that it wouldn't be always win. When we have a lot of
> duplicates, current implementation searches among the pages containing
> those duplicates for the first page containing enough of free space.
> While with unique index, we would have to always insert into
> particular page. Thus, current implementation gives us better filling
> of pages, and (probably) faster insertion.
You're definitely right that that's the weakness of the design.
> But, unique index would
> give us much better performance of retail tuple delete and update
> (currently we don't support both). But I believe that future
> pluggable table access methods will use both.
Right.
> Therefore, my idea is that there is a tradeoff between making btree
> index unique or non-unique. I think we will need an option for that.
> I'm not yet sure if this option should be user-visible or
> auto-decision based on table access method used.
I agree.
--
Peter Geoghegan
