RE: pgsql is 75 times faster with my new index scan
От | Mikheev, Vadim |
---|---|
Тема | RE: pgsql is 75 times faster with my new index scan |
Дата | |
Msg-id | 8F4C99C66D04D4118F580090272A7A23018D22@SECTORBASE1 обсуждение исходный текст |
Ответ на | pgsql is 75 times faster with my new index scan (devik@cdi.cz) |
Список | 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
В списке pgsql-hackers по дате отправления: