From: | nunks <nunks(dot)lol(at)gmail(dot)com> |
---|---|
To: | Scott Ribe <scott_ribe(at)elevated-dev(dot)com> |
Cc: | Wells Oliver <wells(dot)oliver(at)gmail(dot)com>, pgsql-admin <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: [pgsql-admin] "Soft-hitting" the 1600 column limit |
Date: | 2018-06-06 17:13:44 |
Message-ID: | CACq6szR7Q--tw67ZJL4-T59oAXCLXgmCDFVh=FunY3N4HCDLXg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Thank you all for your answers.
David and Tom's answers are more than enough to feed my argument to the
developers. =)
Scott, you're right of course. My first action to reestablish their
development database was to do a dump/restore, but by logging DML
statements I can see the application is dropping and adding the same column
over and over again, so it's a matter of time before it hangs. I hope
showing this thread to the developers will make them see some sense.
@Wells, don't ask me, I have no idea, hahah, but it's a small table and the
application keeps dropping/readding the column, actually. I figure the
developer is using some kind of crazy ORM that drops the column when he
deletes an object property and re-adds it when he sets the property back or
something.
@Ervin, a vacuum full doesn't "fix" this behavior, since it's expected
after all =)
collimittest=# \d add_drop_text
Table "public.add_drop_text"
Column | Type | Collation | Nullable | Default
--------+------+-----------+----------+---------
fixed | text | | |
collimittest=# vacuum FULL ANALYZE VERBOSE add_drop_text ;
INFO: vacuuming "public.add_drop_text"
INFO: "add_drop_text": found 0 removable, 0 nonremovable row versions in 0
pages
DETAIL: 0 dead row versions cannot be removed yet.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
INFO: analyzing "public.add_drop_text"
INFO: "add_drop_text": scanned 0 of 0 pages, containing 0 live rows and 0
dead rows; 0 rows in sample, 0 estimated total rows
VACUUM
collimittest=# alter table add_drop_text add column x int;
ERROR: tables can have at most 1600 columns
----------
“Life beats down and crushes the soul and art reminds you that you have one.”
- Stella Adler
On Wed, Jun 6, 2018 at 1:57 PM, Scott Ribe <scott_ribe(at)elevated-dev(dot)com>
wrote:
> He's *NOT* doing anything that requires 1600 columns--that was pretty much
> the point of his post.
>
> --
> Scott Ribe
> scott_ribe(at)elevated-dev(dot)com
> https://www.linkedin.com/in/scottribe/
>
>
>
> > On Jun 6, 2018, at 10:53 AM, Wells Oliver <wells(dot)oliver(at)gmail(dot)com>
> wrote:
> >
> > let's just stop for a moment and talk about what you're doing that
> requires *1600 columns* because my jaw is hitting the floor.
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Wells Oliver | 2018-06-06 18:43:22 | Re: [pgsql-admin] "Soft-hitting" the 1600 column limit |
Previous Message | Scott Ribe | 2018-06-06 16:57:41 | Re: [pgsql-admin] "Soft-hitting" the 1600 column limit |