From: | "Ansley, Michael" <Michael(dot)Ansley(at)intec(dot)co(dot)za> |
---|---|
To: | "'pgsql-general(at)postgresql(dot)org'" <pgsql-general(at)postgresql(dot)org> |
Subject: | RE: pgsql-general-digest V1 #365 |
Date: | 1999-06-28 07:29:03 |
Message-ID: | 1BF7C7482189D211B03F00805F8527F70ECFAE@S-NATH-EXCH2 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, 25 Jun 1999, Jim Jennis wrote:
>>> 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.
I'm so pleased to find out that somebody else has picked this up. In fact,
the summary tables that I'm working on are a kind of mini-warehouse, the
just happen to reside in the same tablespace as the transactional tables.
However, data warehousing is quite an important issue. I know that most of
the people who use PG work on transactional systems, but if anyone tries to
run even a small warehouse on PG it's going to get complicated very quickly.
On Sat, 26 Jun 1999, Dustin Sallings wrote:
>>> Creating lots of indices is far different from creating a single
>>> index on a lot of fields. Data warehousing is the former. The problem
is
>>> that you can't create a single index with a large number of fields.
Not entirely true. Sometimes the level of summary can require more than
seven fields in an index, normally the primary index.
MikeA...
From | Date | Subject | |
---|---|---|---|
Next Message | Mario Jorge Nunes Filipe | 1999-06-28 09:16:39 | Re: [GENERAL] What does this mean ? |
Previous Message | Remigiusz Sokolowski | 1999-06-28 06:08:21 | Re: [GENERAL] What does this mean ? |