From: | Jim Jennis <jhjennis(at)shentel(dot)net> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: [GENERAL] Date: Fri, 25 Jun 1999 09:56:12 +0200 |
Date: | 1999-06-25 21:47:47 |
Message-ID: | 3.0.5.32.19990625174747.007be4e0@pop.shentel.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)fuentez(dot)com
jhjennis(at)shentel(dot)net
---------------------------------------------------
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Chalmers | 1999-06-25 22:31:08 | Definitive list of new types in 6.5 needed |
Previous Message | Shikatronics See Hyun Lee | 1999-06-25 21:18:16 | How do I know next OID number? |