Re: [GENERAL] Date: Fri, 25 Jun 1999 09:56:12 +0200
От | Jim Jennis |
---|---|
Тема | Re: [GENERAL] Date: Fri, 25 Jun 1999 09:56:12 +0200 |
Дата | |
Msg-id | 3.0.5.32.19990625174747.007be4e0@pop.shentel.net обсуждение исходный текст |
Ответ на | ("Ansley, Michael" <Michael.Ansley@intec.co.za>) |
Ответы |
Re: [GENERAL] Date: Fri, 25 Jun 1999 09:56:12 +0200
(Dustin Sallings <dustin@spy.net>)
|
Список | pgsql-general |
Not only legacy apps, but data warehousing. Frequently in a production environment you use two sets of tables -- production and data warehousing...One (production) with "bare bones" indicies to maximize transaction performance, and one (a replicate in the data warehouse) that you "index the living daylights out of" so that the non db saavy managers who want to do ungodly joints and sorts on tables for organizational reporting get decent performance. just my .02 Jim At 03:59 6/25/99 -0400, you wrote: >>>> > I've been attempting to port applications from Pervasive SQL to PG. >>>> > Pervasive is interesting because it runs on top of btrieve. This allow >>>> > legacy apps >>>> > and SQL systems to co-exist. It's quirky and buggy, but it's better >than PG >>>> > because it can do the following. >>>> > >>>> > >>>> > 1. Have more than 7 fields on a btree index >>>> >>>> We have never understood why someone would want an index with more than >>>> seven columns. > >Legacy apps, Bruce. Sometimes you come across tables with ten fields in the >index. I'm working on a (fairly specialised) system now where the primary >key of one of the tables has twenty-four fields in it. It is a summary >table, and probably not the best design, but that's the way it is, and I >have to live with it. Unfortunately, because we don't have a database that >can have that many fields in a key, we have to construct manual indices in >code. Even Oracle (which is what we are using) only goes up to about 21 or >something. However, if you are going to summarise heavily, then the number >of fields in your primary key can get quite large. >How difficult would it be to make the number of fields in an index unlimited >(or arbitrarily large). Perhaps there could be a compile-time variable >which is defaulted to 7, but which can be increased using the configure >script (./configure --with-index-fields=24). I realise that there are >performance issues, but that's a trade off that only the system designers >can make. > >MikeA... > > ,-,-. ,-,-. ,-,-. ,-,-. ,- / / \ \ / / \ \ / / \ \ / / \ \ / / \ \ / / \ \ / / \ \ / / \ \ / / `-'-' `-'-' `-'-' `-'-' -------------------------------------------------------- FSC - Building Better Information Technology Solutions- From the Production Floor to the Customer's Door. -------------------------------------------------------- Jim Jennis, Technical Director, Commercial Systems Fuentez Systems Concepts, Inc. 1 Discovery Place, Suite 2 Martinsburg, WV. 25401 USA. Phone: +001 (304) 263-0163 ext 235 FAX: +001 (304) 263-0702 Email: jjennis@fuentez.com jhjennis@shentel.net ---------------------------------------------------
В списке pgsql-general по дате отправления:
Предыдущее
От: slee@shikatronics.com (Shikatronics (See Hyun Lee))Дата:
Сообщение: How do I know next OID number?