Re: More then 1600 columns? - Mailing list pgsql-general

From Mark Mitchell
Subject Re: More then 1600 columns?
Date
Msg-id 037315b5-2c5f-49cf-843f-05aaf49c4adc@riccagroup.com
Whole thread Raw
In response to Re: More then 1600 columns?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
Apologizes Tom I did not see that you had answered yes to my question about the hard limit.
You have all been very helpful, I will give up on the 1600+ columns and look into using hstore.

Cheers

- Mark

-----Original Message-----
From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-owner@postgresql.org] On Behalf Of Tom Lane
Sent: Friday, November 12, 2010 11:09 AM
To: Mark Mitchell
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] More then 1600 columns?

"Mark Mitchell" <mmitchell@riccagroup.com> writes:
> 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
itsown field. I had lots of comments on why I should not do this and the possible alternatives and I thank everyone for
theirinput but no one answered the question about compiling with a higher block size to get more columns. Can anyone
answerthat? 

Yes, I did answer it: there is no such compilation option.

If you were willing to run a very nonstandard version of Postgres, you
could try widening t_hoff (see src/include/access/htup.h) but there is
nobody who can tell you what the fallout from that might be.  One big
concern that I would have is the likelihood of O(N^2) behavior on very
long query targetlists.

On the whole I think you'd be a lot better off looking into hstore,
especially the improved 9.0 version.

            regards, tom lane

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


pgsql-general by date:

Previous
From: Paul Taylor
Date:
Subject: Can you check in SQL if a fields can be encoded using specified charset
Next
From: postgresql.30.miller_2555@spamgourmet.com
Date:
Subject: Advice on efficient approach to aggregation statistics