Re: possible patch to increase number of hash overflow pages?
От | Stephen Ramsey |
---|---|
Тема | Re: possible patch to increase number of hash overflow pages? |
Дата | |
Msg-id | Pine.LNX.4.21.0106191858440.23630-100000@sramsey.ocp.internap.com обсуждение исходный текст |
Ответ на | Re: possible patch to increase number of hash overflow pages? (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: possible patch to increase number of hash overflow pages?
|
Список | pgsql-patches |
Bruce, Sure, I would be happy to look into this. I'm a Postgres beginner, so it may take me a while to get up to speed. But am happy to develop and run some tests, identify potential or actual issues or problems, and attempt to remedy any issues I might find. Cheers, Steve Ramsey --------------------------------------------- Stephen Ramsey Software Engineer Core Software Development Internap Network Services e-mail sramsey@internap.com telephone 206.504.5361 facsimile 206.447.1870 --------------------------------------------- On Tue, 19 Jun 2001, Bruce Momjian wrote: > > It looks (from the hash algorithm code) as if the system is possibly > > needing more splitpoints than can be accomodated by the HashMetaPageData > > structure, rather than running out of overflow pages, because the error > > message that I'm getting is when the "splitnum" variable is greater than > > NCACHED, the latter being the array bound for the hashm_spares[] element > > of the HashMetaPageData structure. From src/backend/access/hashovfl.c: > > > > #define OVMSG "HASH: Out of overflow pages. Out of luck.\n" > > > > if (offset > SPLITMASK) > > { > > if (++splitnum >= NCACHED) > > elog(ERROR, OVMSG); > > metap->OVFL_POINT = splitnum; > > metap->SPARES[splitnum] = metap->SPARES[splitnum - 1]; > > metap->SPARES[splitnum - 1]--; > > offset = 0; > > } > > > > So that's why I bumped the number of bits (in the OverflowPageAddress > > type) assigned to keep track of splitpoints to 8 bits. > > If you want to work on the hash stuff, let us know. We are looking for > someone to do performance testing and debugging on hash indexes. > > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 > >
В списке pgsql-patches по дате отправления: