331–336 of 336 posts
Earlier quoted context omitted.
5 Gigawatts to Kilowatts = 5000000 5000000 kilowatts / 1kW per machine = 5,000,000 machines internationally?
Yes, and that's a conservative lower bound (their web application servers likely draw much less than a kilowatt each and constitute a healthy portion of the fleet).
Earlier quoted context omitted.
Yes, and that's a conservative lower bound (their web application servers likely draw much less than a kilowatt each and constitute a healthy portion of the fleet).
Global warming wise, should society really be focusing on using paper straws or should Facebook aim to make their server code 10% more efficient?
can it do DDL commands in a transaction yet?
I always see people asking about this. But why? Are you making schema changes that frequently?
Because I used to have to do that all the time seemingly before I finally got to pick my toolchain and I chose Postgres
Earlier quoted context omitted.
It's my opinion that schema changes should be cheap, fast and unexciting. Unfortunately, in my experience once you are operating at scale they are expensive, slow and fraught with peril. The result is that engineering teams often chose to build poorly designed schemas and take on technical debt rather than make a schema change to a core table. This is a terrible anti-pattern! I'm massively in favour of anything that…
yeah treating every schema change as a db migration might be our industry's worst anti-pattern. transactional ddl allows you to do stuff like: begin tran ..refactor data, drop/create tables.. ..create backwards-compatible views.. commit ..against a live database without risking consistency
Earlier quoted context omitted.
FANG would buy them if they had somehow managed to stumble forward to the mid-2010s.
Zero offers from any of them, so.
Earlier quoted context omitted.
yeah treating every schema change as a db migration might be our industry's worst anti-pattern. transactional ddl allows you to do stuff like: begin tran ..refactor data, drop/create tables.. ..create backwards-compatible views.. commit ..against a live database without risking consistency
I would have very few cases where that works for me. Because I almost always need the database layer to continue to work for a time with both the old code and the new code update. Deployments usually roll out to pods a few at a time so changing the schema of a table suddenly will immediately throw errors all over the place.
that's what the backwards-compatible views are for