Return-Path: mao
Received: by postgres.Berkeley.EDU (5.61/1.29)
	id AA14505; Wed, 29 Jul 92 15:07:53 -0700
Message-Id: <9207292207.AA14505@postgres.Berkeley.EDU>
From: <mao@postgres.berkeley.edu>
Subject: Re: Arrays
To: postgres@postgres.berkeley.edu
Sender: pg_adm@postgres.berkeley.edu
In-Reply-To: Your message of Tue, 28 Jul 92 12:45:29 PST.
             <9207282005.AA00920@postgres.Berkeley.EDU> 
Date: Wed, 29 Jul 92 15:18:32 PDT

In message <9207282005.AA00920@postgres.Berkeley.EDU> you write:

> In more detail, I'm suggesting that relation[index] should apply to
> any relation (including, but not limited to, special array relations)
> which has only two fields.  Index would select on the first column and
> the matching value in the second column would be returned.  It would
> be an error if there were two matches, since arrays are functions.

this is a very interesting idea.  here are some problems i can see:

    +  the additional overhead of maintaining a class for every array
       of ten ascii characters is prohibitive.

    +  storing a tuple per element is pretty inefficient.  tuple
       headers in postgres are 64 bytes, so your elements have to
       be pretty big (or your array pretty sparse) before overhead
       stops killing you.

    +  there's an implicit assumption that the keys of the array
       elements is in some way descriptive of their ordering.  this
       doesn't lead to incorrect behavior, but may, for example,
       lead to poor performance if logically adjacent entries in an
       array are wildly distant from one another physically.

i'll bring this up at the next postgres group meeting to see if anyone
else has reactions.  if nothing else, this may be a sensible way to
provide support for sparse arrays of scientific data.  thanks for
sending your ideas along.
					mike olson
					project sequoia 2000
					uc berkeley
					mao@cs.berkeley.edu