Hi, On 2018-03-03 10:36:18 +0100, Fabien COELHO wrote: > Why would committers prevent pgbench to be used to reproduce this kind of > load?
The goal of *discussing* whether a feature is worth the cost is obviously not to deprive users of features. I find that is a fairly absurd, and frankly insulting, ascription of motives. I didn't "veto" the patch or anything, nor did Tom. I wondered whether we're adding more cost than overall gains. We have very few people that actually show up when there are bugs and fix them, and adding more code tends to make maintenance harder. > The point of pgbench is to be able to test different kind of > loads/scenarii... Accepting such features, if the implementation is > good enough, should be no brainer, and alas it is not. Reviewing whether the implementation is good enough *does* use resources. Our scarcest resource isn't patch contributions, it's dealing with review and maintenance. A lot of contributors, including serial ones, don't even remotely put in as much resources reviewing other people's patches as they use up in reviewer and committer bandwidth. You certainly have contributed more patches than you've reviewed for example. That fundamentally can't scale, unless some individual contribute way more review resources than they use up, and that's not something many people afford nor want. And while possibly not universally seen that way, in my opinion, and I'm not alone seeing things that way, contributors that contribute more review resources than they "use", are granted more latitude in what they want to do because they help the project scale. Note that pgbench code does add work, even if one is not using the new features. As you know, I was working on performance and robustness improvements, and to make sure they are and stay correct I was attempting to compile postgres with -fsanitize=overflow - which fails because pgbench isn't overflow safe. I reported that, but you didn't follow up with fixes. > Note that I'd wish that at least the ready-for-committer bug-fixes would be > processed by committers when tagged as ready in a timely fashion (say under > 1 CF), which is not currently the case. Yes, we're not fast enough to integrate fixes. That's largely because there's few committers that are active. I fail to see how that is an argument to integrate *more* code that needs fixes. I entirely agree that not getting ones patches can be very demoralizing. But unless somebody manages to find a few seasoned developers and pays them to focus on review and maintenance, I don't see how that is going to change. And given scant resources, we need to prioritize. Greetings, Andres Freund
