On 11/12/2010 08:38 AM, Mark Mitchell wrote:
> Yes I understand that this is "bad design" but what we are doing is storing each form field in a survey in its own column. For very long surveys we end up with thousands of elements.
> I know storing in an array is possible but it makes it so much easier to query the data set when each element is in its own field. I had lots of comments on why I should not do this and the possible alternatives and I thank everyone for their input but no one answered the question about compiling with a higher block size to get more columns. Can anyone answer that?
>
> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
> Sent: Friday, November 12, 2010 12:24 AM
> To: Mark Mitchell
> Cc: pgsql-general(at)postgresql(dot)org
> Subject: Re: [GENERAL] More then 1600 columns?
>
> "Mark Mitchell" <mmitchell(at)riccagroup(dot)com> writes:
>> Is there are hard limit of 1600 that you cannot get around?
>
> Yes.
>
> Generally, wanting more than a few dozen columns is a good sign that you
> need to rethink your schema design. What are you trying to accomplish
> exactly?
>
> regards, tom lane
>
>
You can answer this yourself. Save chunks of the survey each in their
own table all keyed with a single id. I'm betting you don't write all
1600 fields at once (or your willing to seriously piss-off the data
entry staff when stuff happens trying to save the last "page"). select *
from table1, table 2 ... where table1.id = table2.id and table2.id =
table3.id .... Then you don't have to ensure that you custom postgres
is "everywhere you want to be".