Return-Path: postarch
Received: by postgres.Berkeley.EDU (5.61/1.29)
	id AA08931; Fri, 3 Jul 92 10:43:36 -0700
Message-Id: <9207031743.AA08931@postgres.Berkeley.EDU>
From: postarch (Postgres Mailing Archive)
Subject: Re: internal storage???
To: postgres@postgres.berkeley.edu
Sender: pg_adm@postgres.berkeley.edu
Reply-To: mer@postgres.berkeley.edu
In-Reply-To: Your message of "Fri, 19 Jun 92 12:44:13 PDT."
             <9206191944.AA27690@postgres.Berkeley.EDU> 
Date: Fri, 03 Jul 92 10:43:28 PDT

you write:

> 	I guess also that I don't understand what "bytea" means?
> Retrieving real_amp[1] always seems to return "{"?? I was stupidly
> under the impression that a byte array would store (at the very least)
> byte numbers between 0-127.  

As I understand it bytea is short for byte array.  So I would say that
your impression is correct.  There are bugs in the array implementation
in 3.1, so when you were using attributes of type bytea[] you were
probably bumping into them.

> 	The signal datum are all 8-bit numbers. Seeing as I have so
> many of the durn things to store I figured that compacting the data in
> the database would be a good thing. After having problems with bytea I
> tried using an array of int2 (int2[]). Unfortunately reading from the
> disk files using the "copy" command only gets 0's instead of the
> actual numbers. Is their a bug fix for this that I'm missing?? I
> haven't checked too recently to see if any new bugs in 3.1 have been
> fixed?? 
> 	Yesterday I changed the int2[] into int4[]. Now it works!! It
> reads the disk files, and has reduced the size of the db from over
> 100Mb down to about 40Mb. This size seems to jive better with your
> calculations, but internally still involves using 4bytes to store
> information that could be easily stored with only one byte. 

hmm... this seems really strange, and quite possibly another bug in the
system.  Postgres attempts to pack bytes on a page as densely as possible,
but maybe the bytea adt doesn't do such a good job.  When 4.0 comes out
(or even in 3.1) try using char[] instead of bytea.  It would be interesting
to see if that does better.

Jeff Meredith
mer@postgres.berkeley.edu