Return-Path: postarch
Received: by postgres.Berkeley.EDU (5.61/1.29)
	id AA22082; Mon, 6 Apr 92 15:57:23 -0700
Message-Id: <9204062257.AA22082@postgres.Berkeley.EDU>
From: postarch (Postgres Mailing Archive)
Subject: Re: "large" classes
To: postgres@postgres.berkeley.edu
Sender: pg_adm@postgres.berkeley.edu
Reply-To: mer@postgres.berkeley.edu
In-Reply-To: Your message of "Fri, 03 Apr 92 20:47:50 PST."
             <9204040447.AA22653@postgres.Berkeley.EDU> 
Date: Mon, 06 Apr 92 15:57:08 PDT

you write:

> Now, I don't typically normalize the daylights out of things, especially for
> throwaway datasets that I often use.  So, my tables are often very wide.  Upon
> trying such a wide monster with Postquel, I run into problems; the "copy from"
> command seems to load the table with garbage, "append" seems to go off into
> the ozone, etc.  So, I normalized the original data somewhat (outside of
> Postquel) and tried again, and presto, things worked.  So OK, I now have a
> more elegant design, but the question lingers: is there some obvious limit
> to the number of attributes within a class?  Is there a good place in the
> docs/src to look for things like this, or should I spend late hours searching
> the entrails of the code for clues?  Or am I way off base?

If you were to "spend late hours searching the entrails of the code for clues"
you would find that the hardwired limit is defined by:

	#define MaxHeapAttributeNumber  1600            /* 8 * 200 */

But I can guarantee you that this limit is not well tested.  Another
limit is that each tuple must fit within a single page (8k), unless you use
the large object interface.  It sounds to me like you may have come across
a bug.  I would be interested to see the schema definition to find out what's
really going on.


Jeff Meredith
mer@postgres.berkeley.edu