Обсуждение: 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