Re: [GENERAL] Date: Fri, 25 Jun 1999 09:56:12 +0200

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

In response to

  • at 1999-06-25 07:56:12 from Ansley, Michael

Responses

Browse pgsql-general by date

  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?