Re: 2018-03 Commitfest Summary (Andres #1) - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: 2018-03 Commitfest Summary (Andres #1)
Date
Msg-id alpine.DEB.2.20.1803310935270.23311@lancre
Whole thread Raw
In response to Re: 2018-03 Commitfest Summary (Andres #1)  (Bruce Momjian <bruce@momjian.us>)
Responses Re: 2018-03 Commitfest Summary (Andres #1)  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
Hello Bruce,

> Has anyone considered moving pgbench out of our git tree and into a
> separate project where a separate team could maintain and improve it?

The movements has been the exact reverse: it was initially in contrib 
where it had some independence, and has been promoted to the main source 
tree by Peter Eisentraut in March 2015, effective on 9.5 release.

Not sure why... Handy dev tool for testing? One regression test in pgbench 
is really testing some postgres feature, and it could be used more for 
this purpose (eg generating a continuous stream of sql stuff to test 
failover, replication, ...).

As pointed out by Pavel, there is significant code sharing with psql 
(scanner, \if stuff), which may grow even more if pgbench client-side 
expressions are moved there as well (whether this is actually desired is 
pretty unclear, though).

So I do not think it would be desirable or practical to have it outside.

However, it helps explain the disagreements about pgbench features: 
pgbench internal developer-oriented use for postgres is somehow limited, 
and a lot of new features are suggested with an external performance 
benchmarking use in mind, about which core committers do not seem much 
interested.

-- 
Fabien.


pgsql-hackers by date:

Previous
From: Nikhil Sontakke
Date:
Subject: Re: Feature Request - DDL deployment with logical replication
Next
From: Fabien COELHO
Date:
Subject: Re: csv format for psql