This patch changes the way pgbench outputs its latency log files so that every transaction gets a timestamp and notes which transaction type was executed. It's a one-line change that just dumps some additional information that was already sitting in that area of code. I also made a couple of documentation corrections and clarifications on some of the more confusing features of pgbench.

It's straightforward to parse log files in this format to analyze what happened during the test at a higher level than was possible with the original format. You can find some rough sample code to convert this latency format into CVS files and then into graphs at http://www.westnet.com/~gsmith/content/postgresql/pgbench.htm which I'll be expanding on once I get all my little patches sent in here.

If you recall the earlier version of this patch I submitted, it added a cleanup feature that did a vacuum and checkpoint after the test was finished and reported two TPS results. The idea was to quantify how much of a hit the eventual table maintenance required to clean up after the test would take. While those things do influence results and cause some of the run-to-run variation in TPS (checkpoints are particularly visible in the graphs), after further testing I concluded running a VACUUM VERBOSE and CHECKPOINT in a script afterwards and analyzing the results was more useful than integrating something into pgbench itself.

--
* Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD
Index: contrib/pgbench/README.pgbench
===================================================================
RCS file: /projects/cvsroot/pgsql/contrib/pgbench/README.pgbench,v
retrieving revision 1.15
diff -c -r1.15 README.pgbench
*** contrib/pgbench/README.pgbench      21 Oct 2006 06:31:28 -0000      1.15
--- contrib/pgbench/README.pgbench      1 Apr 2007 00:57:48 -0000
***************
*** 94,103 ****
                default is 1.  NOTE: scaling factor should be at least
                as large as the largest number of clients you intend
                to test; else you'll mostly be measuring update contention.
  
        -D varname=value
!               Define a variable. It can be refereed to by a script
!               provided by using -f option. Multile -D options are allowed.
  
        -U login
                Specify db user's login name if it is different from
--- 94,107 ----
                default is 1.  NOTE: scaling factor should be at least
                as large as the largest number of clients you intend
                to test; else you'll mostly be measuring update contention.
+               Regular (not initializing) runs using one of the
+               built-in tests will detect scale based on the number of
+               branches in the database.  For custom (-f) runs it can
+               be manually specified with this parameter.
  
        -D varname=value
!               Define a variable. It can be refered to by a script
!               provided by using -f option. Multiple -D options are allowed.
  
        -U login
                Specify db user's login name if it is different from
***************
*** 139,147 ****
                with the name "pgbench_log.xxx", where xxx is the PID
                of the pgbench process. The format of the log is:
  
!                       client_id transaction_no time
  
!               where time is measured in microseconds.
  
        -d
                debug option.
--- 143,157 ----
                with the name "pgbench_log.xxx", where xxx is the PID
                of the pgbench process. The format of the log is:
  
!                       client_id transaction_no time file_no time-epoch time-us
  
!               where time is measured in microseconds, , the file_no is
!               which test file was used (useful when multiple were
!               specified with -f), and time-epoch/time-us are a
!               UNIX epoch format timestamp followed by an offset
!               in microseconds (suitable for creating a ISO 8601
!               timestamp with a fraction of a second) of when
!               the transaction completed.
  
        -d
                debug option.
***************
*** 163,168 ****
--- 173,180 ----
  
    (7) end;
  
+ If you specify -N, (4) and (5) aren't included in the transaction.
+ 
  o -f option
  
    This supports for reading transaction script from a specified
Index: contrib/pgbench/pgbench.c
===================================================================
RCS file: /projects/cvsroot/pgsql/contrib/pgbench/pgbench.c,v
retrieving revision 1.62
diff -c -r1.62 pgbench.c
*** contrib/pgbench/pgbench.c   13 Mar 2007 09:06:35 -0000      1.62
--- contrib/pgbench/pgbench.c   1 Apr 2007 00:57:49 -0000
***************
*** 461,467 ****
                        diff = (int) (now.tv_sec - st->txn_begin.tv_sec) * 
1000000.0 +
                                (int) (now.tv_usec - st->txn_begin.tv_usec);
  
!                       fprintf(LOGFILE, "%d %d %.0f\n", st->id, st->cnt, diff);
                }
  
                if (commands[st->state]->type == SQL_COMMAND)
--- 461,468 ----
                        diff = (int) (now.tv_sec - st->txn_begin.tv_sec) * 
1000000.0 +
                                (int) (now.tv_usec - st->txn_begin.tv_usec);
  
!                       fprintf(LOGFILE, "%d %d %.0f %d %ld %ld\n",
!                               st->id, st->cnt, diff, st->use_file, 
now.tv_sec,now.tv_usec);
                }
  
                if (commands[st->state]->type == SQL_COMMAND)
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Reply via email to