Message-Id: <200208061528.RAA21080@localhost.localdomain>
Content-Type: text/plain;
  charset="iso-8859-1"
From: Joerg Hessdoerfer <Joerg.Hessdoerfer@sea-gmbh.com>
Organization: S.E.A Datentechnik GmbH
To: Richard Huxton <dev@archonet.com>
Subject: Re: Table design question...
Date: Tue, 6 Aug 2002 17:24:53 +0200
References: <200208060921.LAA20528@localhost.localdomain>
	<200208061039.MAA20640@localhost.localdomain>
	<200208061359.53726.dev@archonet.com>
In-Reply-To: <200208061359.53726.dev@archonet.com>
Cc: pgsql-sql@postgresql.org
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Hi again,

On Tuesday 06 August 2002 14:59, you wrote:
[...]
> If your exports are all of one type (i.e. all arrays or all integer or all
> float) I'd go for (B) since that makes things nice and easy. On the other
> hand, if you want to export different types in one query you'll need to do
> a union unless you put all possible fields in one table:
>
> CREATE TABLE data_all (
>   scet		timestamp,
>   recv	timestamp,
>   data_type	char(1) CHECK (data_type IN ('i','f','a')),
>   intval	int4,
>   floatval	float,
>   arr_names	int4[],
>   arr_values	int4[]
> );
>
> If you go the route of (A) or (B) I'd run a few tests to see which is more
> efficient. You can always hide the implementation details behind a view and
> some functions.
>
> - Richard Huxton
>
[...]

Yes, I'm currently going the testing route - my initial idea was also 
something like your table def above, but this rules itself out (I really 
think 500,000,000 rows is a bit too much ;-). Don't get me wrong, I think a 
'big iron' could manage that easily, but I need to make do with a quite 
common PeeCee (running Linux, that is)...

Thanks again for your input,
	Joerg
-- 
Leading SW developer  - S.E.A GmbH
Mail: joerg.hessdoerfer@sea-gmbh.com
WWW:  http://www.sea-gmbh.com