Greetings, * Justin Pryzby (pry...@telsasoft.com) wrote: > On Thu, Jul 09, 2020 at 06:58:40PM -0400, Stephen Frost wrote: > > * Peter Geoghegan (p...@bowt.ie) wrote: > > > On Thu, Jul 9, 2020 at 7:03 AM Stephen Frost <sfr...@snowman.net> wrote: > > > It makes more sense than simply ignoring what our users will see as a > > > simple regression. (Though I still lean towards fixing the problem by > > > introducing hash_mem, which at least tries to fix the problem head > > > on.) > > > > The presumption that this will always end up resulting in a regression > > really doesn't seem sensible to me. > > Nobody said "always" - we're concerned about a fraction of workloads which > regress, badly affecting only only a small fraction of users.
And those workloads would be addressed by increasing work_mem, no? Why are we inventing something new here for something that'll only impact a small fraction of users in a small fraction of cases and where there's already a perfectly workable way to address the issue? > Maybe pretend that Jeff implemented something called CashAgg, which does > everything HashAgg does but implemented from scratch. Users would be able to > tune it or disable it, and we could talk about removing HashAgg for the next 3 > years. But instead we decide to remove HashAgg right now since it's > redundant. > That's a bad way to transition from an old behavior to a new one. It's scary > because it imposes a burden, rather than offering a new option without also > taking away the old one. We already have enable_hashagg. Users are free to disable it. This makes it also respect work_mem- allowing users to tune that value to adjust how much memory HashAgg actually uses. > > > That's not the only justification. The other justification is that > > > it's generally reasonable to prefer giving hash aggregate more memory. > > > > Sure, and it's generally reasonably to prefer giving Sorts more memory > > too... as long as you've got it available. > > I believe he meant: > "it's generally reasonable to prefer giving hash aggregate more memory THAN > OTHER NODES" If we were developing a wholistic view of memory usage, with an overall cap on how much memory is allowed to be used for a query, then that would be an interesting thing to consider and discuss. That's not what any of this is. Thanks, Stephen
signature.asc
Description: PGP signature
