Re: [HACKERS] Re: Postgres Features for 7.X - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [HACKERS] Re: Postgres Features for 7.X
Date
Msg-id 200001100516.AAA19314@candle.pha.pa.us
Whole thread Raw
In response to Re: [HACKERS] Re: Postgres Features for 7.X  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> Bruce Momjian <pgman@candle.pha.pa.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...

Oh, OK.

> 
> > 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 :-(

I have looked at every 8 in the source tree, and I think I have them
all.  I have now moved INDEX_MAX_KEYS to config.h.in, where it belongs.

I have not changed the type names.  I am going to keep them called int28
and oid8 until we decide we want them to be 16 and I will change the
type names.  They function fine as oid8 even if they are 16 long.  :-)

I am not sure how the index code handles this so I am a little scared to
bump it up by default.

There was really only some code in oid8in and int28in that required
recoding because the sscanf was using 8 params.  The new code loops
over an sscanf.  The other changes were just replacement of 8 with the
define.


> 
> 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...

Oh, OK, just make it 16.  That should work, and be a good way to test my
changes.  However, I am not sure everything will work so I will keep it
at 8 until we can test it to see what happens.  Only very large data
sets with very long indexes is going to trigger the index code.

May as well see if someone _knows_ if the index code will work with >8
indexed fields.

--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


pgsql-hackers by date:

Previous
From: "Hiroshi Inoue"
Date:
Subject: RE: [HACKERS] Number of index fields configurable
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Number of index fields configurable