4 ms·

I wonder what stuff like this means in terms of electrical impact around the world at scale. I'm being dramatic obviously but like... less CPU cycles, less net

I wonder what stuff like this means in terms of electrical impact around the world at scale. I'm being dramatic obviously but like... less CPU cycles, less network bandwidth, etc. etc. If adopted by top 100 "large" database/operations, is it as much as like 100 people giving up their gas/petrol/diesel car?

peterfirefly 3y ago
https://en.wikipedia.org/wiki/Jevons_paradox https://en.wikipedia.org/wiki/Jevons_paradox
- flockonus 3y ago
  Glad I've learned about this fascinating effect, but it doesn't seem reasonable that such a niche improvement on Postgresql backup would have an impact on the price of electricity or another resource.
  - fastball 3y ago
    No, but you could imagine a situation where a feature added to a database makes people more likely to use that database, even in places where maybe a "lighter weight" database (e.g. SQLite) would've been good enough, therefore increasing electricity usage overall.
    - peterfirefly 3y ago
      That + many more people will take backups (and most of those will be unnecessary).
    - flockonus 3y ago
      Still, imho, hardly the scale to have the effect visible, if you think how many servers exist vs. the electricity demand reduction. One example I'd find reasonable, perhaps the Apple Silicon M family has a shot at it, when comparing the energy draw diff (less than half of Intel's equivalent) multiply by the adoption at scale.. maybe that. One more straightforward that definitely have a chance at achieving the effect: LED lightbulbs: huge consumption reduction, huge scale.
devnonymous 3y ago
I'm willing to bet that beyond a certain threshold there's no use for an incremental backup. You either would use (delayed) replication[1] to have an 'incremental' copy or would take full backups. I don't think any large database users rushing to use incremental backups when they have full redundancy. [1] for example https://about.gitlab.com/blog/2019/02/13/delayed-replication-for-disaster-recovery-with-postgresql/ https://about.gitlab.com/blog/2019/02/13/delayed-replication...
- rhaas 3y ago
  I agree that for many use cases, standbys and in particular time-delayed standbys are a better option than backups. That said, having off-line backups in tamper-proof storage is a good call, too.
fbdab103 3y ago
I think about this every time I see my corporate laptop spinning up because of bloated malware detection software, Teams, OneDrive, etc all seemingly unoptimized and burning resources across hundreds of millions of machines worldwide.
mosselman 3y ago
I did a thought experiment with made up numbers. I just woke up so forgive me if my numbers don’t add up. At least they can serve as ballpark numbers. Let’s say a full backup takes 3 hours and an incremental one 3 minutes. Let’s say I want at most 3 hours of lag in my backups. That would mean 3 hours every 3 hours. That is about 720 hours per month for a full backup or 720 minutes (12 hours) for incremental backups. Let’s say we Still do a full one once a day then that is still 102 hours per month in total. Even if you do 1 incremental per hour you’d end up at 36 hours a month. If 3 minutes were true for the every 3 hour scenario, the every 1 hour scenario would also mean shorter backups so maybe 1 minute, which adds up to 12 hours. All this to say that it might be more efficient.
- scoot 3y ago
  > Let’s say I want at most 3 hours of lag AKA Recovery Point Objective (RPO)

peterfirefly 3y ago

https://en.wikipedia.org/wiki/Jevons_paradox https://en.wikipedia.org/wiki/Jevons_paradox

flockonus 3y ago
Glad I've learned about this fascinating effect, but it doesn't seem reasonable that such a niche improvement on Postgresql backup would have an impact on the price of electricity or another resource.
- fastball 3y ago
  No, but you could imagine a situation where a feature added to a database makes people more likely to use that database, even in places where maybe a "lighter weight" database (e.g. SQLite) would've been good enough, therefore increasing electricity usage overall.
  - peterfirefly 3y ago
    That + many more people will take backups (and most of those will be unnecessary).
  - flockonus 3y ago
    Still, imho, hardly the scale to have the effect visible, if you think how many servers exist vs. the electricity demand reduction. One example I'd find reasonable, perhaps the Apple Silicon M family has a shot at it, when comparing the energy draw diff (less than half of Intel's equivalent) multiply by the adoption at scale.. maybe that. One more straightforward that definitely have a chance at achieving the effect: LED lightbulbs: huge consumption reduction, huge scale.

devnonymous 3y ago

I'm willing to bet that beyond a certain threshold there's no use for an incremental backup. You either would use (delayed) replication[1] to have an 'incremental' copy or would take full backups. I don't think any large database users rushing to use incremental backups when they have full redundancy. [1] for example https://about.gitlab.com/blog/2019/02/13/delayed-replication-for-disaster-recovery-with-postgresql/ https://about.gitlab.com/blog/2019/02/13/delayed-replication...

rhaas 3y ago
I agree that for many use cases, standbys and in particular time-delayed standbys are a better option than backups. That said, having off-line backups in tamper-proof storage is a good call, too.

fbdab103 3y ago

I think about this every time I see my corporate laptop spinning up because of bloated malware detection software, Teams, OneDrive, etc all seemingly unoptimized and burning resources across hundreds of millions of machines worldwide.

mosselman 3y ago

I did a thought experiment with made up numbers. I just woke up so forgive me if my numbers don’t add up. At least they can serve as ballpark numbers. Let’s say a full backup takes 3 hours and an incremental one 3 minutes. Let’s say I want at most 3 hours of lag in my backups. That would mean 3 hours every 3 hours. That is about 720 hours per month for a full backup or 720 minutes (12 hours) for incremental backups. Let’s say we Still do a full one once a day then that is still 102 hours per month in total. Even if you do 1 incremental per hour you’d end up at 36 hours a month. If 3 minutes were true for the every 3 hour scenario, the every 1 hour scenario would also mean shorter backups so maybe 1 minute, which adds up to 12 hours. All this to say that it might be more efficient.

scoot 3y ago
> Let’s say I want at most 3 hours of lag AKA Recovery Point Objective (RPO)