From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Rod Taylor <rbt(at)rbt(dot)ca> |
Cc: | "A(dot)M(dot)" <agentm(at)cmu(dot)edu>, pgsql-sql(at)postgresql(dot)org |
Subject: | Re: Column limits in table/ views |
Date: | 2003-06-09 14:22:23 |
Message-ID: | 17237.1055168543@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
Rod Taylor <rbt(at)rbt(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | george young | 2003-06-09 19:21:12 | find open transactions/locks in 7.2? |
Previous Message | Alexey Dashevsky | 2003-06-09 14:21:03 | left join in cursor |