OH: "PostgreSQL is the Linux of databases" It's probably equally unstoppable and will completely dominate the database ecosystem in the next 10-20 years. What's your opinion on this?
-
-
Replying to @lukaseder @MarkusWinand
I think that "one size fits all" is a myth.
#PostgreSQL has many technical advantages, but two problems damage it a lot: 1) its community doesn't make criticism, which is essential to improve 2) there is no proper bug tracker6 replies 5 retweets 15 likes -
tbh no one likes taking criticism.. try proposing as recommendations instead of criticisms
3 replies 0 retweets 0 likes -
Make actually meant make. I'm not complaining about some bad reply I received, it didn't happen. I'm observing that the PostgreSQL community only says great things about their favorite DB. As a consequence, most of them don't feel that its flaws should be fixed.
6 replies 0 retweets 1 like -
I can definitely agree with that. Try discussing the benefits of a sophisticated execution plan cache (e.g. Oracle's) with them
3 replies 0 retweets 2 likes -
Replying to @lukaseder @FedericoRazzol1 and
I'd be curious as to who you talk to :-) most of the people I talk to in the postgres community would definitely want access to those benefits (whether by an identical solution or not is a different question, but something to solve the same very much existing problem)
5 replies 0 retweets 2 likes -
Replying to @magnushagander @lukaseder and
We've long claimed: - our planner is so good we don't need hints and that when it's not you should tell us and we fix it (we don't) - our replication story is good - that nobody wants/should want automated failover - our IO stack is a good idea - not using threading is awesome …
4 replies 4 retweets 15 likes -
Replying to @AndresFreundTec @magnushagander and
I'd add autovacuum. But I understand that getting rid of it requires a major architectural change and I don't know if it's realistically possible.
2 replies 0 retweets 0 likes -
Replying to @FedericoRazzol1 @magnushagander and
There's plenty more. Not sure about autovacuum in particular however: While our scheduling around it needs improvement, there's also some substantial gains from not needing full undo. FWIW, it's definitely fixable. There are actually quite a few patches around undo/zheap out.
2 replies 0 retweets 0 likes -
Replying to @AndresFreundTec @magnushagander and
It's more the need for vacuum, CoW, transactions wraparound, etc. I'd be happy if some day the way PostgreSQL writes data changes.
1 reply 0 retweets 0 likes
Sure, got that. Just think that the cost of other approaches are often underestimated. And I've spent a fair bit over the last ~2-3 years working around allowing different approaches to work in PG. Some of the costs of what you mentioned aren't costs intrinsic to in-heap mvcc.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.