6 ms·
One thing that made me slightly iffy in one of the usecases Postgres would be a no brainer is the need to vacuum for dead tuples. I was quite sketched by it and
by bettercallsalad 3y ago
One thing that made me slightly iffy in one of the usecases Postgres would be a no brainer is the need to vacuum for dead tuples. I was quite sketched by it and instead opted for traditional NoSQL stack. I wonder how people with large volumes of UPSERTs deal with vacuuming, isn’t it a huge operational burden?
- johndalton 3y agoFor most folks autovacuum "Just Works", transparently and in the background. For people with large volumes of UPSERTs or similar workloads with lots of activity against existing rows, it may be necessary to tune autovacuum - usually to be more aggressive than the defaults. Aside from figuring out that this is a thing that can be done and then doing it (or paying someone to figure this out for you), there really isn't much operational burden involved. I have seen cases where it made sense to run regularly scheduled vacuums outside of just leaving it all to autovacuum, but in my experience this is rare - when I see someone worrying about vacuums it's usually the case that they should just change an autovacuum knob and then forget about it.
- TOMDM 3y agoCome on man I'm not even 30, I'm way too young to be made to feel old by people saying "traditional NoSQL stack".
- justinclift 3y agoThere are some interesting things in development to potentially solve that problem. Here's a recent HN submission about OrioleDB of the more promising ones: https://news.ycombinator.com/item?id=36740921 https://news.ycombinator.com/item?id=36740921 Source code: https://github.com/orioledb/orioledb https://github.com/orioledb/orioledb