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.smith@crunchydatasolutions.com
Chief PostgreSQL Evangelist - http://crunchydatasolutions.com/