From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Stephen Ramsey <sramsey(at)internap(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: possible patch to increase number of hash overflow pages? |
Date: | 2001-06-19 23:46:02 |
Message-ID: | 200106192346.f5JNk2C21641@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2001-06-20 00:00:51 | Re: [PATCHES] [PATCH] Contrib C source for casting MONEY to INT[248] and FLOAT[48] |
Previous Message | Bruce Momjian | 2001-06-19 23:41:11 | Re: use GUC for cmdline |