News for hackers. Stuff that matters.

A comment on PostgreSQL anti-patterns: read-modify-write cycles (2014). Parent comment

Re:PostgreSQL anti-patterns: read-modify-write cycles (2014) by rejschaap on Wednesday December 21, 2016 @05:02AM (#13227970)
The space concerns depend on the usage. But in general I feel people worry too much and too early about this. People also worry about calculating balance being not efficient. You need really large amounts of data before any of this becomes a problem. When it does become a problem it can be solved by caching.

I think the more realistic concern with this approach is that some queries might get complicated when they involve more complex logic based on the balance.

[ Parent | on HN ]
Re:PostgreSQL anti-patterns: read-modify-write cycles (2014) by mtanski on Wednesday December 21, 2016 @09:27AM (#13229314)
> When it does become a problem it can be solved by caching.

Solved or made worse by caching?

[ Parent | on HN ]
Re:PostgreSQL anti-patterns: read-modify-write cycles (2014) by dsp1234 on Wednesday December 21, 2016 @11:47AM (#13230529)
made worse by caching

Caching may relieve some stress (on say a dashboard), but if an application is doing calculations around account balances, and uses event sourcing-like structures in the database, then caching isn't going to help as those calculations are going to still need to be done for each new balance changing event.

So caching is never worse (unless you accidentally used the cached value where you needed the live value), but isn't necessarily going to relieve a lot of DB stress.

[ Parent | on HN ]
Re:PostgreSQL anti-patterns: read-modify-write cycles (2014) by cookiecaper on Friday December 23, 2016 @03:57PM (#13247196)
Since it's append-only, can't you "cache" or snapshot the calculation in pieces? e.g., "Today @ 00:00 all events on this account summed up to 100." Then you just replay today's events. You don't have to recalculate anything unless you're changing your transformations. Make your checkpoints whatever interval is necessary to make on-demand event replay acceptably performant.
[ Parent | on HN ]