RE: pgsql is 75 times faster with my new index scan

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

Responses

Browse pgsql-hackers by date

  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