On Thu, 2006-09-21 at 07:52 -0700, yoav x wrote:
> After upgrading DBI and DBD::Pg, this benchmark still picks MySQL as the winner (at least on Linux
> RH3 on a Dell 1875 server with 2 hyperthreaded 3.6GHz CPUs and 4GB RAM).
> I've applied the following parameters to postgres.conf:
> max_connections = 500
> shared_buffers = 3000
That's a low setting. 3000*8192 = 24MB. This should probably be closer
to 25% total memory, or 1GB, or 131072 shared buffers (however, that's
just a rule of thumb, there may be a better setting).
> work_mem = 100000
> effective_cache_size = 3000000000
That is a very high setting. effective_cache_size is measured in disk
pages, so if you want 3GB the correct setting is 393216.
> Most queries still perform slower than with MySQL.
> Is there anything else that can be tweaked or is this a limitation of PG or the benchmark?
As others have pointed out, sql-bench may not be a realistic benchmark.
The best way to examine performance is against real work.
Also, consider that relational databases were not developed to increase
performance. Things like filesystems are inherently "faster" because
they do less. However, relational databases make development of systems
of many applications easier to develop, and also make it easier to make
a well-performing application. If the benchmark isn't testing anything
that a filesystem can't do, then either:
(a) Your application could probably make better use of a relational
(b) The benchmark doesn't represent your application's needs.
In response to
pgsql-performance by date
|Next:||From: Bucky Jordan||Date: 2006-09-21 19:13:55|
|Subject: Re: Large tables (was: RAID 0 not as fast as|
|Previous:||From: Tom Lane||Date: 2006-09-21 15:12:45|
|Subject: Re: PostgreSQL and sql-bench |