head     1.4;
branch   ;
access   ;
symbols  ;
locks    ; strict;
comment  @# @;


1.4
date     91.08.17.22.14.40;  author postgres;  state Exp;
branches ;
next     1.3;

1.3
date     91.08.17.05.32.35;  author kemnitz;  state Exp;
branches ;
next     1.2;

1.2
date     91.08.17.05.31.06;  author kemnitz;  state Exp;
branches ;
next     1.1;

1.1
date     91.08.15.08.36.30;  author kemnitz;  state Exp;
branches ;
next     ;


desc
@Wisconsin readme.
@


1.4
log
@replaced "input" with "output"
@
text
@The Postgres Wisconsin Benchmark

In this directory are the queries and raw data files used to populate the
Postgres version of the Wisconsin benchmark.  In order to run the benchmark,
you'll initially need to execute the script

./create.sh

which will populate the "bench" database, create the indices, and vacuum the
database.  This will take from 10 minutes or so on a Sparc II/DECstation 5000
class machine to an hour on a Sun 3.

Once create.sh completes, you can execute the benchmark by running the
script

./runwisc.sh

into an output file.  This output file may be quite large (300K or so)
so make sure you have sufficient disk space.  Once the benchmark run has
completed, query execution times can be obtained by running the 

./perquery

script on the output file.  It will generate a nicely formatted, numbered
set of output with times for each query indicated.  (Note that each query
is run twice.)

  !!! WARNING!  DO NOT RUN THESE SCRIPTS IF THE POSTMASTER IS RUNNING !!!
@


1.3
log
@asdfklj
@
text
@d24 1
a24 1
script on the input file.  It will generate a nicely formatted, numbered
@


1.2
log
@added a couple of remarks about populating things.
@
text
@d27 2
@


1.1
log
@Initial revision
@
text
@d9 3
a11 3
which will populate the initial database and create all the indices.  This
will create a database called "bench" and, for best results the Postquel
query
d13 2
a14 1
> vacuum
a15 5
should be executed on the "bench" database after the create.sh script
completes.  This will update all the instance commit information so that
verification by the access methods can be done at the best speed.  Once this
has done, the benchmark can be executed by running the

d18 1
a18 1
script into an output file.  This output file may be quite large (300K or so)
@
