3 ms·
OP talks about having to wait 32 minutes to dump a 35GB database. That's nothing. I could do that every day without breaking a sweat. Thanks to ACID, it doesn't
by kijin 8y ago
OP talks about having to wait 32 minutes to dump a 35GB database. That's nothing. I could do that every day without breaking a sweat. Thanks to ACID, it doesn't even matter if other users are modifying the database during those 32 minutes. It matters even less if you're dumping a slave.
But how about waiting a whole day to dump a 5TB database? It would have been a major pain in the ass if the real-world customer I'm talking about had chosen to store all their files in the database. Thankfully the files are stored elsewhere, so the database only weighs about 80GB. That's small enough to dump, pipe to gzip, pipe to ssh, and store in a remote location every single day.
- 1337shadow 8y agoWhat desperate me, is that it takes 32 minutes to dump relational data of a baby project with not even 100k relations. Re-dumping binary files over and over again when it should not be necessary ... it's getting worse every day. Add to this that Bob the manager will get you a new server only when you fill up your server and you might get tired of it too. They also don't keep files 33 months old or something, which means that postgresql is also going to have to deal with space efficiently on removal on a regular basis. Files in PostgreSQL, works for PostgreSQL, but that becomes a bottleneck in automated deployment. It's 95% of the deployment time and growing, is this a timeframe where we should take down the service writes or no that's another question to deal with.