Re: [HACKERS] Re: Postgres Features for 7.X

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: [HACKERS] Re: Postgres Features for 7.X
Дата
Msg-id 200001100516.AAA19314@candle.pha.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] Re: Postgres Features for 7.X  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: "Hiroshi Inoue"
Дата:
Сообщение: RE: [HACKERS] Number of index fields configurable
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] Number of index fields configurable