3 ms·
> If you have high concurrent updates When do you not have concurrency? > you should be dealing with append-only database design and collapsing into a view to
by the_mitsuhiko 13y ago
> If you have high concurrent updates
When do you not have concurrency?
> you should be dealing with append-only database design and collapsing into a view to query, like Datomic
True, but postgres is very bad at that. So you need to work with the tools that postgres gives you. Yes postgres currently does not give you an upsert but an upsert is much closer to postgres' design than an append only database that denormalizes on inserts.
- hcarvalhoalves 13y ago> When do you not have concurrency? Highly concurrent updates? By that I understand a workload where you have multiple clients updating the same rows. In my experience it's either rare or the result of doing something inefficiently (e.g., doing analytics as a "view_count" column). Everytime I've faced that I've remodeled the database, both for performance (you avoid invalidating caches for the entire table) and auditing reasons (if you have a bunch of people replacing each other's changes, you might want to retain the history).
- justintocci 13y agovery bad at what? i lost you.