Re: possible patch to increase number of hash overflow pages?
От | Bruce Momjian |
---|---|
Тема | Re: possible patch to increase number of hash overflow pages? |
Дата | |
Msg-id | 200106192346.f5JNk2C21641@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: possible patch to increase number of hash overflow pages? (Stephen Ramsey <sramsey@internap.com>) |
Ответы |
Re: possible patch to increase number of hash overflow
pages?
|
Список | pgsql-patches |
> 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 по дате отправления: