From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | John Huttley <john(at)mwk(dot)co(dot)nz>, PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: [HACKERS] Re: Postgres Features for 7.X |
Date: | 2000-01-10 04:56:21 |
Message-ID: | 2068.947480181@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
>> I've just remembered the other problem with PG that needs to be listed for
>> fixing.
>>
>> This is the 7 field index limit
It's 8, not 7, afaik...
> I am working on this now. 7.0 will have a postgres.h parameter that can
> be changed. Default is 8.
I looked at this a while ago and realized that the fundamental problem
is that pg_index depends on types oid8 and int28 (hardwired 8-element
arrays of oid and int2, respectively). Are you going to rename these
types to oidN and int2N and make the value of N a config parameter?
Seems like a good idea ... but that magic constant 8 is buried in
a depressingly large number of places, a lot of which aren't even
symbolic constants :-(
If you do fix this, I'd suggest bumping the default N up to 16 or so;
seems like that would make a lot of people happier than N=8...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Hiroshi Inoue | 2000-01-10 05:09:25 | RE: [HACKERS] Number of index fields configurable |
Previous Message | Tom Lane | 2000-01-10 04:48:31 | Re: [HACKERS] Re:HEAP_MOVED_IN during vacuum - test case |