Re: pgbench more operators & functions
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: Fabien COELHO <coelho@cri.ensmp.fr>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Stephen Frost <sfrost@snowman.net>, Jeevan Ladhe <jeevan.ladhe@enterprisedb.com>, PostgreSQL Developers <pgsql-hackers@postgresql.org>
Date: 2016-10-08T10:47:29Z
Lists: pgsql-hackers
On Sat, Oct 8, 2016 at 12:58 PM, Fabien COELHO <coelho@cri.ensmp.fr> wrote: > > 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. > FWIW, sometime back I have seen that with fill factor 80, at somewhat moderate client counts (32) on 192 - Hyper Threaded m/c, the performance is 20~30% better, but at higher client counts, it was same as 100 fill factor. I think if go by your theory, one could also argue to have non-default values autovacuum threshold parameters. pgbench already has a parameter to specify non-default fillfactor and I think that is sufficient for anyone to do performance testing. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
Commits
-
Improve scripting language in pgbench
- bc7fa0c15c59 11.0 landed