Ok folks, here is my view (very opinionated) on the history of
Every 5 years, we had a major leap. Something that met some big need, closed a huge gap.
1/5
Conversation
Something I’ve always struggled with regarding PostgreSQL is properly identifying what’s worth going into the next release from the end users perspective. Noobish question: How does the dev team receive that feedback and decide?
3
I generally go looking for feedback (e.g. reading forums). Lack of access to good user feedback is a problem, though - getting the nuance across may really matter. Stories about atypical bad experiences are often more informative than "typical cases", for the obvious reason.
1
3
I believe that DBAs (not devs) generally care about avoiding big shocks most of all. It really is about real world values and priorities. Having DBA input could easily lead to a design that makes better trade-offs. Might even make it easier to implement.
1
3
Heh. Hello new best friend. I’ve been puzzling over ways to get more DBAs involved in productive ways. No ground breaking or brilliant ideas yet.
1
1
Hello! So take the Gitlab thing again. It's easy for me to assume that this is "just a corner case" if it gets presented in an abstract way - because that's kind of true. OTOH "this was the worst day of my DBA life, by far" is much more informative because of context.
1
1
4
I actually reached out to gitlab about their index bloat issues a couple of years back, following a really good blog post about it. If nothing else it motivated me to focus on the problem; I at least knew that bloat was overwhelmingly in indexes (not tables) with their app.
1
4
It is very much on Postgres to behave predictably. Most individual queries are already more than fast enough, and so real world stability matters more and more every year. But it's hard (sometimes impossible) to measure in an abstract way.