Re: Fixed xloginsert_locks for 9.4

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(dot)smith(at)crunchydatasolutions(dot)com
Chief PostgreSQL Evangelist - http://crunchydatasolutions.com/