On 10/3/14, 10:11 AM, Andres Freund wrote:
So 25% performance on a relatively small machine improvements aren't worth a GUC? That are likely to be larger on a bigger machine? I utterly fail to see why that's a service to our users.
I didn't say that. I said I don't think they're worth a GUC today if it can be quietly and automatically slipped into the next release--and that seems quite feasible. I have introduced GUCs that almost no one can tune properly into the system before. Can't say I was pleased with how that played out.
Another thing I don't know yet, and this is going to take me a while to characterize, is how that 25% gain on a benchmark that is specifically designed to highlight the problem use case impacts the various mixes of more average cases I try as well. Is it 0.1% for a typical pgbench workload? Now that GUC isn't so exciting anymore either.
And there's one more big issue I'd prefer not to discover from real-world complaints: is there any downside to making this number very large on a system where it shouldn't be?
The history of settings like this says that providing an exposed knob will result in some people tinkering it with and making the system slower. The gain of going from 1 to 8 is so clear and simple that I'm not worried too hard about performance regressions like that. But if we make it a GUC and it can be set to 100 to extract maximum performance on big machines...I'd take a bet that we'll find people setting it to 100 saying "more must be better" where it isn't. Every time someone wanders into pgsql-performance with a complaint, each one of these obscure GUCs they tweaked magnifies the troubleshooting mess a little.
I do not disagree with you fundamentally here: this *is* worth refining further, for sure, and the gains might be even greater if that keeps going. My guess is just that the Postgres community would not get a net benefit chasing that as a GUC in 9.4, not by the time you try to account for all the future overhead and risk that adds to the release. That was Heikki's gut feel on this when he yanked it out already; I was mainly trying to do sanity checking on that. You've made a good case that wasn't the ideal answer. Even with that new data, I still don't think it was a outright bad decision though--especially not in an October where there's no new version out yet. This thread spun out of Open Items, and cutting complexity should be the preferred direction for everything left on there now.
-- Greg Smith greg.sm...@crunchydatasolutions.com Chief PostgreSQL Evangelist - http://crunchydatasolutions.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
