Re: [HACKERS] PostgreSQL Benchmarks

Why don't we include a postgresql.conf.recommended along with our
postgresql.conf.sample. That shouldn't be too hard. We can just jack up
the shared buffers and wal buffers and everything - it doesn't matter if
it's not perfect, but it will at least give people an idea of what needs to
be increased, etc to get good results.

I'm currently benchmarking our new DB server before we put it into
production. I plan to publish the results from that shortly.

Regards,

Chris

> -----Original Message-----
> From: pgsql-advocacy-owner(at)postgresql(dot)org
> [mailto:pgsql-advocacy-owner(at)postgresql(dot)org]On Behalf Of Merlin Moncure
> Sent: Tuesday, 11 February 2003 11:44 PM
> To: Greg Copeland
> Cc: PostgresSQL Hackers Mailing List; pgsql-advocacy(at)postgresql(dot)org
> Subject: Re: [pgsql-advocacy] [HACKERS] PostgreSQL Benchmarks
>
>
> 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
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>