Обсуждение: Re: [HACKERS] Bizarre coding in _bt_binsrch
> The main problem is just programistic: you will have to add > heap tid to the end of index tuples on internal index pages, > but on leaf pages heap tid is in the begin of index tuples > (inside of btitem struct). > While I absolutely like the idea of having the heap tid in the index, I don't quite agree, that leaf pages need heap tid at the front of the key. This would lead to Index access beeing not ordered (in terms of key) :-( Having it in the front will only lead to "on disk ordered" fetches while reading tuples from one leaf page, when reading the next leaf page you will start from the beginning. So I think the leaf page needs heap tid at the end of each key, same as in root pages. For performance reasons a totally standalone "sort to tuple on disk order" node could be implemented, that could also be handled by the optimizer, and would be of wider performance use. Andreas
ZEUGSWETTER Andreas IZ5 wrote: > > > The main problem is just programistic: you will have to add > > heap tid to the end of index tuples on internal index pages, > > but on leaf pages heap tid is in the begin of index tuples > > (inside of btitem struct). > > > While I absolutely like the idea of having the heap tid in the index, > I don't quite agree, that leaf pages need heap tid at the front of the key. Oh no - this is not what I meant to say. First, there is no heap tid in index tuples in internal pages, and so we'll have to add it to them. Actually, it doesn't matter where to add it - just after btitem->bti_itup (i.e. header of index tuple) or after field keys - it will be the last key used in comparing. But on leaf pages index tuples already keep heap tid - this is btitem->bti_itup.t_tid - and so we shouldn't add heap tid there. I just wanted to say that we'll have to differentiate internal/leaf index tuples in _bt_compare, _bt_binsrch etc to know from what part of index tuples heap tid should be fetched. Sorry. Vadim
ZEUGSWETTER Andreas IZ5 wrote: > > For performance reasons a totally standalone "sort to tuple on disk order" > node could be implemented, that could also be handled by the > optimizer, and would be of wider performance use. We'll get tuples from index scan sorted on [key, disk order]. Vadim