| From: | John Frank <jrf(at)segovia(dot)mit(dot)edu> | 
|---|---|
| To: | <pgsql-general(at)postgresql(dot)org> | 
| Subject: | Out of overflow pages. Out of luck. | 
| Date: | 2001-01-24 05:27:54 | 
| Message-ID: | Pine.LNX.4.30.0101240025240.6320-100000@segovia.mit.edu | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-general | 
pgsql-general:
Does anyone have experience hacking the HASH index code to allow more
overflow pages?
I get the following when indexing a table with about 300M entries:
db=# \d table1
       Table "table1"
 Attribute |     Type     | Modifier
-----------+--------------+----------
 field1    | varchar(256) |
 field2    | integer      |
 field3    | float8       |
db=# create index table1_field1 on table1 using hash(field1);
ERROR:  HASH: Out of overflow pages.  Out of luck.
This also happens for field2.
I looked in the source for postgresql-7.0.3 from
src/include/access/hash.h:
 * The reason that the size is restricted to NCACHED (32) is because
 * the bitmaps are 16 bits: upper 5 represent the splitpoint, lower 11
 * indicate the page number within the splitpoint. Since there are
 * only 5 bits to store the splitpoint, there can only be 32 splitpoints.
 * Both spares[] and bitmaps[] use splitpoints as there indices, so there
 * can only be 32 of them.
 */
#define NCACHED                 32
Is there a way around this?! If not: what a horrific limitation.
Thanks! John
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Willis, Ian (Ento, Canberra) | 2001-01-24 05:45:44 | RE: MySQL has transactions | 
| Previous Message | Joseph N. Hall | 2001-01-24 05:19:12 | Re: MySQL has transactions |