RE: v7.1b4 bad performance

I would consider this perfectly acceptable. Official benchmarks can only be
without the -F switch prior to 7.1, so in raw performance terms (with
acceptable safety) you have to compare 7.0.2 without -F to 7.1beta4 with -F,
because those are the fastest configurations with acceptable recovery.
However, I would also expect 7.0.2 -F to be faster than 7.1beta4 -F, because
7.1beta4 is doing more (WAL specifically). Over the same plans, the engine
is doing more work, so must be slower.

Thoughts...

MikeA

-----Original Message-----
From: Tom Lane
To: Schmidt, Peter
Cc: 'Bruce Momjian'; 'Michael Ansley'; 'pgsql-admin(at)postgresql(dot)org'
Sent: 2-16-01 11:40 PM
Subject: Re: [ADMIN] v7.1b4 bad performance

FWIW, I get the following pgbench results on my machine (HPPA C180,
fast-wide-SCSI drives that I do not recall the specs for):

current sources, with -F

$ pgbench -t 1000 bench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1
number of clients: 1
number of transactions per client: 1000
number of transactions actually processed: 1000/1000
tps = 26.493155(including connections establishing)
tps = 26.558319(excluding connections establishing)
$ pgbench -c 10 -t 100 bench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1
number of clients: 10
number of transactions per client: 100
number of transactions actually processed: 1000/1000
tps = 25.812518(including connections establishing)
tps = 26.161266(excluding connections establishing)

current sources, without -F

$ pgbench -t 1000 bench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1
number of clients: 1
number of transactions per client: 1000
number of transactions actually processed: 1000/1000
tps = 12.843274(including connections establishing)
tps = 12.864183(excluding connections establishing)
$ pgbench -c 10 -t 100 bench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1
number of clients: 10
number of transactions per client: 100
number of transactions actually processed: 1000/1000
tps = 12.593353(including connections establishing)
tps = 12.676020(excluding connections establishing)

7.0.2, with -F

$ pgbench -p 5432 -t 1000 bench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1
number of clients: 1
number of transactions per client: 1000
number of transactions actually processed: 1000/1000
tps = 48.925826(including connections establishing)
tps = 49.199684(excluding connections establishing)
$ pgbench -p 5432 -c 10 -t 100 bench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1
number of clients: 10
number of transactions per client: 100
number of transactions actually processed: 1000/1000
tps = 43.664810(including connections establishing)
tps = 45.067229(excluding connections establishing)

7.0.2, without -F

$ pgbench -p 5432 -t 1000 bench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1
number of clients: 1
number of transactions per client: 1000
number of transactions actually processed: 1000/1000
tps = 5.678665(including connections establishing)
tps = 5.682127(excluding connections establishing)
$ pgbench -p 5432 -c 10 -t 100 bench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1
number of clients: 10
number of transactions per client: 100
number of transactions actually processed: 1000/1000
tps = 5.780491(including connections establishing)
tps = 5.796646(excluding connections establishing)

In short, about 2x faster when you compare the fsync (no -F) cases,
but slower when you compare the no-fsync cases. This may just be
because current sources have to do more I/O to write the WAL log as
well as the data files, but I'm not convinced of that... trying to
get some profile info ...

regards, tom lane

**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
Nick West - Global Infrastructure Manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************