5 ms·
You don't understand it because he doesn't understand the problem well enough to explain it, which is why he ever had this problem in the first place.
by vorotato 9y ago
You don't understand it because he doesn't understand the problem well enough to explain it, which is why he ever had this problem in the first place.
- shredprez 9y agoAny chance we can get a quick post mortem?
- pstuart 9y agoHe used a temp table to stash IDs, like he should have from the start.
- rosenfeld 9y agoAs pstuart mentioned, one of the post mortem was to fix the script, which I did by using a temporary table. The other part was to enable new columns to be added to that table in case we need in the future. For that part, I locked a few tables for writing, recreated them with a separate name and replaced the old with the new one in order to avoid any downtime or dealing with master-slave set-ups to be able to dump and restore without downtimes. Full vacuum freeze wouldn't reclaim that space back.
- lapinrigolo 9y agoMy thoughts exactly.
- rosenfeld 9y agoMaybe I failed to explain it well enough, but I certainly do understand the problem pretty well. If you have any questions just ask and I can tell you the reasons to do what I did. The reason why I had this problem in the first place is that I wasn't aware that dropped columns would still count towards the columns limit in PostgreSQL. It's not a complaint, it's just ignorance. There's a difference between being ignorant and not understanding the problem after it happens. I never claimed to be an expert on PostgreSQL.
- anarazel 9y ago> that I wasn't aware that dropped columns would still count towards the columns limit in PostgreSQL. FWIW, I hope we (the PG devs) will fix that some day.
- rosenfeld 9y agoAwesome, good to hear that :-) Fixed or not, PG is awesome anyway. Thanks for helping to make it the best database I've worked with so far :-)