3 ms·

> people thinking they should have a feature because other databases have it (which seems fair) Literally NO ONE wants query hinting in Postgres to check some

> people thinking they should have a feature because other databases have it (which seems fair) Literally NO ONE wants query hinting in Postgres to check some kind of feature box because other databases have it. We know we want it because…other databases have it, and it's INCREDIBLY USEFUL. > They straight up say that they're willing to consider the idea if somebody wants to say how to do it without the pitfalls of other systems. Pitfalls my ass. We want exactly the functionality that is already present in other systems, pitfalls and all. That's just an excuse to do nothing, Apple-style, "because we know better than our own users" while trying to appear reasonable. It's akin to not adopting SQL until you can do so "while avoiding the pitfalls of SQL." Just utter bullshit.

adamrt 5y ago
> We want exactly the functionality that is already present in other systems, pitfalls and all. That's just an excuse to do nothing Are you offering to help with the maintenance or development associated with it? Or are you just demanding features while calling the people that do help with that stuff liars? Maybe they do know better? Or maybe they know about other hassles that will come with it that you can't fathom. They've been developing and maintaining one of the best open source projects on the planet for nearly 3 decades. Maybe with all that experience, its not their opinion that is BS?
- mst 5y ago
  Given there's already a pg_hint_plan extension I really don't see why people are so angry about the developers not wanting to bless something they consider a footgun as a core feature.
  - zepearl 5y ago
    "risk", because pg_hint is an external module, written by somebody as a hobby, therefore if it stops existing or working after some updates or with newer versions of Postgres then it becomes a huge problem for PROD systems that need it for any reason.
    - mst 5y ago
      My point is that "core developers should add an unproven feature they think is a footgun and take on the support overhead of that without convincing evidence it would actually be a net win" is not a convincing argument. Also given Amazon AWS support it for Aurora, I feel like it's not -that- hobby-ish. If people use it and can provide evidence that it helps more than it hurts, that might be convincing. Insulting the core developers for not yet being convinced seems rather less likely to help.
      - zepearl 5y ago
        > Also given Amazon AWS support it for Aurora, I feel like it's not -that- hobby-ish. Oh, didn't know that :) About the rest: sure, I can agree as well about the indirect adverse effect of having them available (e.g. easy to misuse them as I saw in some apps using Oracle DBs), and it's for sure wrong to insult somebody because of this. Still, personally, I think that the pros would outweight the cons of having that embedded in the app. On one hand I remember some nights spent in the past trying to make some SQL work, hints were always at least a good temporary workaround. On the other hand there will always be some SQL which confuse the optimizer (or more special cases about a lot of data changing distribution of values, etc..) and hints would be the only way to cover these cases. Maybe an interesting question is on which level should hints act? I know mainly only Oracle & MariaDB, therefore I know hints of the type "use that index"/"query tables in this order"/"join these tables with this join type"/etc..., which are probably low-level hints. Maybe already just higher-level hints of the type "most important selectivity criteria comes from inline-view X"/"I want just the first row of the result"/"take into account only plans which select data by using indexes"/etc... would be as well interesting, not sure, just dumping here my thoughts.
    - fomine3 5y ago
      It is written by Telco company.
- ghusbands 5y ago
  Sure, maybe in not doing what every other database does, that really helps users out when they're suffering unpredictable performance, they're demonstrating their far superior knowledge. And maybe all the users that are suffering are somehow incompetent. Or maybe it's just typical developer hubris of the kind that hits everyone at some point.

adamrt 5y ago

> We want exactly the functionality that is already present in other systems, pitfalls and all. That's just an excuse to do nothing Are you offering to help with the maintenance or development associated with it? Or are you just demanding features while calling the people that do help with that stuff liars? Maybe they do know better? Or maybe they know about other hassles that will come with it that you can't fathom. They've been developing and maintaining one of the best open source projects on the planet for nearly 3 decades. Maybe with all that experience, its not their opinion that is BS?

mst 5y ago
Given there's already a pg_hint_plan extension I really don't see why people are so angry about the developers not wanting to bless something they consider a footgun as a core feature.
- zepearl 5y ago
  "risk", because pg_hint is an external module, written by somebody as a hobby, therefore if it stops existing or working after some updates or with newer versions of Postgres then it becomes a huge problem for PROD systems that need it for any reason.
  - mst 5y ago
    My point is that "core developers should add an unproven feature they think is a footgun and take on the support overhead of that without convincing evidence it would actually be a net win" is not a convincing argument. Also given Amazon AWS support it for Aurora, I feel like it's not -that- hobby-ish. If people use it and can provide evidence that it helps more than it hurts, that might be convincing. Insulting the core developers for not yet being convinced seems rather less likely to help.
    - zepearl 5y ago
      > Also given Amazon AWS support it for Aurora, I feel like it's not -that- hobby-ish. Oh, didn't know that :) About the rest: sure, I can agree as well about the indirect adverse effect of having them available (e.g. easy to misuse them as I saw in some apps using Oracle DBs), and it's for sure wrong to insult somebody because of this. Still, personally, I think that the pros would outweight the cons of having that embedded in the app. On one hand I remember some nights spent in the past trying to make some SQL work, hints were always at least a good temporary workaround. On the other hand there will always be some SQL which confuse the optimizer (or more special cases about a lot of data changing distribution of values, etc..) and hints would be the only way to cover these cases. Maybe an interesting question is on which level should hints act? I know mainly only Oracle & MariaDB, therefore I know hints of the type "use that index"/"query tables in this order"/"join these tables with this join type"/etc..., which are probably low-level hints. Maybe already just higher-level hints of the type "most important selectivity criteria comes from inline-view X"/"I want just the first row of the result"/"take into account only plans which select data by using indexes"/etc... would be as well interesting, not sure, just dumping here my thoughts.
  - fomine3 5y ago
    It is written by Telco company.
ghusbands 5y ago
Sure, maybe in not doing what every other database does, that really helps users out when they're suffering unpredictable performance, they're demonstrating their far superior knowledge. And maybe all the users that are suffering are somehow incompetent. Or maybe it's just typical developer hubris of the kind that hits everyone at some point.