From: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> |
---|---|
To: | "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | RE: pgsql is 75 times faster with my new index scan |
Date: | 2000-09-27 22:03:30 |
Message-ID: | 8F4C99C66D04D4118F580090272A7A23018D22@SECTORBASE1 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > It was discussed several times for btree - add heap tid to
> > index key and you'll scan index for particulare tuple much faster.
>
> good idea :) Why don't just to use tid ALWAYS as last part of key ?
> When btree code sees equal keys then it will compare tids ?
> Would not be better to use oids ? The don't change during vacuum
> and with tupleheader in index we will know it.
In some future I would like to make OIDs optional - they are not
always used, so why waste space?
+ using TID would make keys unique and this would simplify
handling of duplicates.
+ heap TID is already part of btitems in leaf nodes - OIDs would just
increase btiem size.
> > Not sure what could be done for hash indices... order hash
> > items with the same hash key?
>
> question is whether we need it for hash indices. it is definitely
> good for btree as they support range retrieval. hash ind. doesn't
> it so I wouldn't implement it for them.
We need in fast heap tuple --> index tuple lookup for overwriting
storage manager anyway...
Vadim
From | Date | Subject | |
---|---|---|---|
Next Message | The Hermit Hacker | 2000-09-28 01:15:40 | The Data Base System is in recovery mode |
Previous Message | Mikheev, Vadim | 2000-09-27 21:46:33 | RE: pgsql is 75 times faster with my new index scan |