From: | ZEUGSWETTER Andreas IZ5 <Andreas(dot)Zeugswetter(at)telecom(dot)at> |
---|---|
To: | pgsql-hackers(at)postgreSQL(dot)org, "'vadim(at)krs(dot)ru'" <vadim(at)krs(dot)ru> |
Subject: | Re: [HACKERS] Bizarre coding in _bt_binsrch |
Date: | 1999-06-07 09:58:39 |
Message-ID: | 219F68D65015D011A8E000006F8590C60267B38B@sdexcsrv1.f000.d0188.sd.spardat.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | ZEUGSWETTER Andreas IZ5 | 1999-06-07 10:11:49 | Re: [HACKERS] Priorities for 6.6 |
Previous Message | ZEUGSWETTER Andreas IZ5 | 1999-06-07 09:18:30 | AW: [HACKERS] livetime of a variable defined in a c-procedure (fw d) |