Bcc: Reply-To: Hi,
On 2018-03-02 10:47:01 +0100, Fabien COELHO wrote: > For instance, I used extensively tps throttling, latencies and timeouts > measures when developping and testing the checkpointer sorting & throttling > patch. That doesn't say that much about proposed feature additions, we didn't say that feature isn't useful? > I can stop doing both if the project decides that improving pgbench > capabilities is against its interest. That's not what we said. There's a difference between "we do not want to improve pgbench" and "the cost/benefit balance seems to have shifted over time, and the marginal benefit of proposed features isn't that high". > As pgbench patches can stay ready-to-committers for half a dozen CF, I'm not > sure the strain on the committer time is that heavy:-) That's just plain wrong. Even patches that linger cost time and attention. > > > As already said, the motivation is that it is a preparation for a (much) > > > larger patch which would move pgbench expressions to fe utils and use them > > > in "psql". > > > > You could submit it together with that. > > Sure, I could. My previous experience is that maintaining a set of dependent > patches is tiresome, and it does not help much with testing and reviewing > either. I'm exactly of the opposite opinion. Submitting things out of context, without seeing at least drafts of later patches, is a lot more work and doesn't allow to see the big picture. > So I'm doing things one (slow) step at a time, especially as each > time I've submitted patches which were doing more than one thing I was asked > to disentangle features and restructuring. There's a difference between maintaining a set of patches in a queue, nicely split up, and submitting them entirely independently. Greetings, Andres Freund