To: Rod Taylor <rbt@rbt.ca>
Cc: "A.M." <agentm@cmu.edu>, pgsql-sql@postgresql.org
Subject: Re: Column limits in table/ views 
In-reply-to: <1054993688.23997.26.camel@jester> 
References: <945001F0-986A-11D7-AAB2-0030657192DA@cmu.edu>
	<1054993688.23997.26.camel@jester>
Comments: In-reply-to Rod Taylor <rbt@rbt.ca>
	message dated "07 Jun 2003 09:48:08 -0400"
Date: Mon, 09 Jun 2003 10:22:23 -0400
Message-ID: <17237.1055168543@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Rod Taylor <rbt@rbt.ca> writes:
> On Fri, 2003-06-06 at 18:02, A.M. wrote:
>> I have 560 columns of NUMERIC(10,14). To not run up against max column=20
>> restraints, I split the information into two tables. Does the column=20
>> limit on tables imply the same limit for views or selects or could I=20
>> potentially select a row across both tables and make a view that hides=20
>> the split?

> The limit is documented as having to do with the size of a block.  The
> largest a single row can become is 8k with primitive types (text, and
> other variable length types will 'overflow' into another area -- see
> TOAST).

> Selects should be able to return more columns than that.  Both views and
> tables create a ROW TYPE to represent it, which is where the limitation
> is.  Thus, I would not expect you to be able to create a view.

But a view row is never stored on disk, so the block-size limit doesn't
come into play.  You will still be constrained by the max column count
(1600), because that comes from the tuple header layout --- the size of
the header plus null bitmap has to fit into a uint8 field.  But a view
with 560 columns would work.

I think some performance issues might come up if you actually try to
select all the columns at once, because there are places whose behavior
is O(N^2) in the number of columns.  Dunno whether this effect will be
noticeable with ~560 columns though.

			regards, tom lane