Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] PostgreSQL Benchmarks

From: "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>
To: "Greg Copeland" <greg(at)CopelandConsulting(dot)Net>
Cc: "PostgresSQL Hackers Mailing List" <pgsql-hackers(at)postgresql(dot)org>,<pgsql-advocacy(at)postgresql(dot)org>
Subject: Re: [HACKERS] PostgreSQL Benchmarks
Date: 2003-02-11 15:44:07
Message-ID: 303E00EBDD07B943924382E153890E5434A909@cuthbert.rcsinc.local (view raw or flat)
Thread:
Lists: pgsql-advocacypgsql-hackerspgsql-performance
I've tested all the win32 versions of postgres I can get my hands on
(cygwin and not), and my general feeling is that they have problems with
insert performance with fsync() turned on, probably the fault of the os.
Select performance is not so much affected.

This is easily solved with transactions and other such things.  Also
Postgres benefits from pl just like oracle.

May I make a suggestion that maybe it is time to start thinking about
tuning the default config file, IMHO its just a little bit too
conservative, and its hurting you in benchmarks being run by idiots, but
its still bad publicity.  Any real database admin would know his test
are synthetic and not meaningful without having to look at the #s.

This is irritating me so much that I am going to put together a
benchmark of my own, a real world one, on (publicly available) real
world data.  Mysql is a real dog in a lot of situations.  The FCC
publishes a database of wireless transmitters that has tables with 10
million records in it.  I'll pump that into pg, run some benchmarks,
real world queries, and we'll see who the faster database *really* is.
This is just a publicity issue, that's all.  Its still annoying though.

I'll even run an open challenge to database admin to beat query
performance of postgres in such datasets, complex multi table joins,
etc.  I'll even throw out the whole table locking issue and analyze
single user performance.

Merlin 



_____________
How much of the performance difference is from the RDBMS, from the
middleware, and from the quality of implementation in the middleware.

While I'm not surprised that the the cygwin version of PostgreSQL is
slow, those results don't tell me anything about the quality of the
middleware interface between PHP and PostgreSQL.  Does anyone know if we
can rule out some of the performance loss by pinning it to bad
middleware implementation for PostgreSQL?


Regards,

-- 
Greg Copeland <greg(at)copelandconsulting(dot)net>
Copeland Computer Consulting




Responses

pgsql-performance by date

Next:From: Tom LaneDate: 2003-02-11 16:20:14
Subject: Changing the default configuration (was Re: [HACKERS] PostgreSQL Benchmarks)
Previous:From: Andrew SullivanDate: 2003-02-11 13:29:27
Subject: Re:

pgsql-hackers by date

Next:From: Greg CopelandDate: 2003-02-11 15:45:41
Subject: Re: PGP signing releases
Previous:From: Tom LaneDate: 2003-02-11 15:41:53
Subject: Re: Hash grouping, aggregates

pgsql-advocacy by date

Next:From: Tom LaneDate: 2003-02-11 16:20:14
Subject: Changing the default configuration (was Re: [HACKERS] PostgreSQL Benchmarks)
Previous:From: Greg CopelandDate: 2003-02-11 14:47:02
Subject: Re: [HACKERS] PostgreSQL Benchmarks

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group