Moving the test to a system with SCSI disks gave different results. 
There is NO difference between having the indexes on the same disk or 
different disk with the data while running pgbench. So I leave it up to
you guys as to include the patch or not.  I do believe that even if
performance doesn't increase, this patch as alot of other benefits for
admins.

Let me know
Jim


> Here is my pgbench results.  As you can see the I am getting 2X tps
with
> the 2 directories.  I believe this is a BIG win for Postgresql if we
can
> figure out the WAL recovery issues.
> 
> 
> Can someone other than me apply the patch and verify the pgbench
> results.
> 
> 
> My hardward setup is a dual processor P3/733 running Redhat 7.1 with
512
> megs of memory. The postgresql.conf file is the installed version with
> NO changes.
> 
> Jim
> 
> 
> template1=# create database one_dir with location='PGDATA1';
> template1=# create database two_dir with location='PGDATA1'
> index_location='PGIDX1';
> for X in 1 2 3 4 5 6 7 8 9 10 
> do
> 	pgbench -i -s 10 one_dir >>one_dir.log
> 	pgbench -i -s 10 two_dir >>two_dir.log
> done
> 
> bash-2.04$ grep 'excluding' one_dir.log
> tps = 44.319306(excluding connections establishing)
> tps = 34.641020(excluding connections establishing)
> tps = 50.516889(excluding connections establishing)
> tps = 52.747039(excluding connections establishing)
> tps = 16.203821(excluding connections establishing)
> tps = 36.902861(excluding connections establishing)
> tps = 52.511769(excluding connections establishing)
> tps = 53.479882(excluding connections establishing)
> tps = 54.599429(excluding connections establishing)
> tps = 36.780419(excluding connections establishing)
> tps = 48.048279(excluding connections establishing)
> 
> bash-2.04$ grep 'excluding' two_dir.log
> tps = 58.739049(excluding connections establishing)
> tps = 100.259270(excluding connections establishing)
> tps = 103.156166(excluding connections establishing)
> tps = 110.829358(excluding connections establishing)
> tps = 111.929690(excluding connections establishing)
> tps = 106.840118(excluding connections establishing)
> tps = 101.563159(excluding connections establishing)
> tps = 102.877060(excluding connections establishing)
> tps = 103.784717(excluding connections establishing)
> tps = 53.056309(excluding connections establishing)
> tps = 73.842428(excluding connections establishing)
> 
> 
> > > Also I have been running this patch (both 7.1.3 and 7.2devel)
> against
> > > some of my companies applications.  I have loaded a small database
> 10G
> > 
> > We are not familiar with your applications. It would be better to
see
> > results of test suit available to the community. pgbench is first to
> > come in mind. Such tests would be more valuable.
> > 
> > Vadim
> > 
> > ---------------------------(end of
> broadcast)---------------------------
> > TIP 4: Don't 'kill -9' the postmaster
> > 
> > 
> 
> 
> 



Wed, 12 Sep 2001 20:18:46 -0400
"Jim Buttafuoco" <jim@buttafuoco.net>
Re: Index location patch for review (more pgbench results)
> Moving the test to a system with SCSI disks gave different results. 
> There is NO difference between having the indexes on the same disk or 
> different disk with the data while running pgbench. So I leave it up to
> you guys as to include the patch or not.  I do believe that even if
> performance doesn't increase, this patch as alot of other benefits for
> admins.

I bet it is the SCSI tagged queueing that is making up for the same disk
performance.  Agreed administration is enough of a need to add the
feature.


-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Wed, 12 Sep 2001 20:49:13 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Index location patch for review (more pgbench results)