Hello Tom,

I comment here on the first part of your remarks. I've answered the second part in another mail.

(1) The required schema is slightly different : currently the type used
for holding balances is not wide enough per the TCP-B standard, this mean
maybe having an option to do "pgbench -i --standard-tpcb" which would
generate the right schema, probably it should just change a few INTEGER to
INT8, or maybe use NUMERIC(10). I have not done such a patch yet.

The whole question of the database setup is an interesting one.
If we were to do anything at all here, I'd want to see not only the table schemas and initial population, but also the hard-wired "vacuum" logic, somehow made not so hard-wired. I have no good ideas about that. The SQL commands could possibly be taken from scripts, but what of all the work that's gone into friendly progress reporting for table loading?

I'm unconvince by the current status, especially the default behaviors. I think it should do a good sensible representative job, and not be a minimum installation.

For instance, the default setup does not use foreign keys. It should be the reverse, foreign keys should be included by default and an option should be used to lessen the schema quality.

Also, given the heavy UPDATE nature of the pgbench test, a non 100% default fill factor on some tables would make sense.

The "friendly progress reporting" only applies to the initial insert: the vacuum, primary key and possibly foreign key alterations also take a significant time but are not included in the progress report. On the one hand that makes sense because pgbench has no clue about the progression of these tasks, but on the other hand it means that the "friendly" stops halfway in the setup. The default progress reporting is much too verbose on any modern hardware, the quiet mode should be the default, or even the only option.

Note that I'm not really planing to change any of this because it would probably be rejected as it is a significant behavioral change, but I find it annoying anyway.


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to