Re: pgbench more operators & functions - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: pgbench more operators & functions
Date
Msg-id alpine.DEB.2.20.1610080853020.15877@lancre
Whole thread Raw
In response to Re: pgbench more operators & functions  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pgbench more operators & functions
List pgsql-hackers
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.

-- 
Fabien



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: pgbench vs. wait events
Next
From: Amit Kapila
Date:
Subject: Re: pgbench more operators & functions