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 think the benefits of a sophisticated plan cache are generally accepted and we'd love to have the feature. The issue is how to make it work with the current architecture, without hurting existing users. So far there were other features with higher priority, better cost/benefit.
1 reply 0 retweets 2 likes -
Replying to @fuzzycz @lukaseder and
IMHO nobody wants a sophisticated plan cache. The reason Oracle has it is because they have failed so many times at plan caching that the stack of fixes looks sophisticated. In the meantime it works mostly. Less sophistication due to fewer incomplete attempts would be better.
4 replies 2 retweets 4 likes -
Replying to @MarkusWinand @fuzzycz and
While I would say that my (long ago) exposure to the plancache in oracle was not great, I don't agree with the general sentiment. The amount of time we spend planning, and the amount of memory we need for our crappy per-backend plancache, is just not reasonable.
1 reply 0 retweets 4 likes -
Replying to @AndresFreundTec @MarkusWinand and
To improve we imo most urgently need: 1) sharing of most common plans to reduce memory usage 2) automated plan generalization to avoid needing separate plans when a parameter would do just as well 3) much better approach to dealing with plans where concrete values are important.
1 reply 0 retweets 4 likes -
Replying to @AndresFreundTec @fuzzycz and
I didn't mean to say that a shared plan cache is not good or useful. I was mostly rumbling about the word 'sophisticated', which has a positive annotation. "somphisticated" is not what I want. Simple, yet doing the job is what I want (I know, this is the hard part).
1 reply 0 retweets 0 likes
Meh. I think pursuing simplicity as the prime goal for problems that just aren't that simple is what leads to things that badly work in the real world. Like our plancache (which is only used for prepared statements, but even there isn't not good enough).
-
-
Replying to @AndresFreundTec @fuzzycz and
Pfuh, I neither didn't mean to say it is the only relevant thing. Maybe the 20/80 rule applies here: 20% sophistication to reach 80% of the benefit.
2 replies 0 retweets 1 like -
Replying to @MarkusWinand @AndresFreundTec and
An example that comes to my mind: Oracle & histograms There are different types of histograms, some deprecated in the meanwhile (very limited from at beginning). Now they have a sophisticated solution, but (in the meanwhile) PostgreSQL has got most of that but less sophisticated
1 reply 1 retweet 0 likes - 2 more replies
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.