Re: pgbench: INSERT workload, FK indexes, filler fix

Hello Greg,

Some quick feedback about the patch and the arguments.

Filling: having an empty string/NULL has been bothering me for some time. 
However there is a significant impact on the client/server network stream 
while initializing or running queries, which means that pgbench older 
performance report would be comparable to newer ones, which is a pain even 
if the new results do make sense, as you noted in a comment. I'm okay with 
breaking that, but it would require a consensus: People would run pgbench 
on a previous install, upgrade, run pgbench again, and report a massive 
performance regression. Who will have to deal with that noise?

A work around could be to add new workloads with different names, and let 
the previous workloads more or less as is.

"--insert-only" as a short hand for "-b insert-only": I do not think this 
is really needed to save 1 char. Also note that "-b i" would probably 
work.

extra indexes: I'm ok on principle. Do we want an option for that though? 
Isn't adding "i" to -I enough? Also I do not like much the code which 
modifies the -I provided string to add a "i".

> After bouncing the possibilities around a little, David and I thought this
> specific set of changes might be the right amount of change for one PG
> version.

Hmmm. I was hoping for more changes:-) Eg the current error handling patch 
would be great.

> benchmark noise from where I started at with PG.  The $750 USD AMD retail
> chip in my basement lab pushes 1M TPS of prepared SELECT statements over
> sockets.  Plus or minus 84 bytes per row in a benchmark database doesn't
> worry me so much anymore.

AFAICR the space is actually allocated by pg and filled with blanks, just 
not transfered by the protocol? For an actual network connection I guess 
the effect should be quite noticeable.

> [...]
> I personally would prefer to see pgbench lead by example here, that tables
> related this way should be indexed with FKs by default, as the Right Way to
> do such things.

I do agree that the default should be the good choices, and that some 
manual effort should be done to get the bad ones. The only issue is that 
people do not like change.

-- 
Fabien.