Re: Index location patch for review (more pgbench results)

From: "Jim Buttafuoco" <jim(at)buttafuoco(dot)net>
To: jim(at)buttafuoco(dot)net, "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>, "'jim(at)buttafuoco(dot)net'" <jim(at)buttafuoco(dot)net>, "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "'Bruce Momjian'" <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Index location patch for review (more pgbench results)
Date: 2001-09-13 00:18:46
Message-ID: 200109130018.f8D0Iki30721@dual.buttafuoco.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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
> >
> >
>
>
>

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2001-09-13 00:49:13 Re: Index location patch for review (more pgbench results)
Previous Message Adam 2001-09-12 22:16:39 count of occurences