Re: ERROR: tables can have at most 1600 columns
От | Alvaro Herrera |
---|---|
Тема | Re: ERROR: tables can have at most 1600 columns |
Дата | |
Msg-id | 20040627194352.GA2910@dcc.uchile.cl обсуждение исходный текст |
Ответ на | ERROR: tables can have at most 1600 columns (Ron St-Pierre <rstpierre@syscor.com>) |
Ответы |
Re: ERROR: tables can have at most 1600 columns
|
Список | 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)
В списке pgsql-general по дате отправления: