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
Autovacuum actually had a big problem, don't know if it changed in the last 2-3 major versions: it wasn't triggered for INSERT only tables. By design, I think. But this was a problem for index visibility map (at least, this was my non-expert analysis of a performance problem)
1 reply 0 retweets 0 likes
Yea, but that's just because we're slow to improve, it's not an inherent issue.
-
-
Replying to @AndresFreundTec @FedericoRazzol1 and
(to be clear: It's not trivial to fix this in a way that doesn't also regress other workloads)
1 reply 0 retweets 1 like -
Replying to @AndresFreundTec @magnushagander and
I'd also add that the commitlog needs checksums. In my understanding it doesn't have them. There could be more areas that need checksums but I'm not aware about.
0 replies 0 retweets 0 likes
End of conversation
New conversation -
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.