> > 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

Wed, 27 Sep 2000 15:03:30 -0700
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
RE: pgsql is 75 times faster with my new index scan
> > 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...
 
oh .. there will be such one ?



Thu, 28 Sep 2000 14:01:14 +0200
devik@cdi.cz
Re: pgsql is 75 times faster with my new index scan