From: | Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> |
---|---|
To: | Ron St-Pierre <rstpierre(at)syscor(dot)com> |
Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: ERROR: tables can have at most 1600 columns |
Date: | 2004-06-27 19:43:52 |
Message-ID: | 20040627194352.GA2910@dcc.uchile.cl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Sun, Jun 27, 2004 at 11:11:32AM -0700, Ron St-Pierre wrote:
> I found this error in /var/log/messages yesterday after a cron job
> wouldn't complete:
> STATEMENT: ALTER TABLE victoria.eodData DROP COLUMN tickDate;
> ERROR: tables can have at most 1600 columns
> STATEMENT: ALTER TABLE victoria.eodData ADD COLUMN tickerID INTEGER;
> ERROR: tables can have at most 1600 columns
> ...etc...
>
> The columns didn't exist at the time I tried to drop them, and \dt
> showed that the table only contained the normal dozen columns.
Have you done the DROP COLUMN/ADD COLUMN cycle to this table more than,
say, 1500 times? Because a dropped column is actually only hidden from
the user, but it's still present to the system and it will still affect
the 1600 limit.
Dropping the table and restoring from a backup would bring it to sanity,
as you found out. And it will probably also get you back some
performance (though it may be so small a gain that you may not notice).
> My question is this: every night the database is vacuumed-full-analyze:
> wouldn't that prevent this condition from happening?
Nope.
--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"The only difference is that Saddam would kill you on private, where the
Americans will kill you in public" (Mohammad Saleh, 39, a building contractor)
From | Date | Subject | |
---|---|---|---|
Next Message | Ben-Nes Michael | 2004-06-27 20:00:57 | Re: Is this a "Stupid Question" ? |
Previous Message | Ron St-Pierre | 2004-06-27 18:11:32 | ERROR: tables can have at most 1600 columns |