You can use the test with InnoDB by giving the --create-options=engine=innodb
option in the
command line. Even with InnoDB, in some specific tests PG looks very bad
compared to InnoDB.
--- Tom Lane [EMAIL PROTECTED] wrote:
yoav x [EMAIL PROTECTED] writes:
Are there any tuning parameters
Hi, Yoav X,
yoav x wrote:
You can use the test with InnoDB by giving the --create-options=engine=innodb
option in the
command line. Even with InnoDB, in some specific tests PG looks very bad
compared to InnoDB.
As far as I've seen, they include the CREATE TABLE command in their
benchmarks.
Have you tuned postgresql ?
You still haven't told us what the machine is, or the tuning
parameters. If you follow Merlin's links you will find his properly
tuned postgres out performs mysql in every case.
--dc--
On 14-Sep-06, at 2:55 AM, yoav x wrote:
You can use the test with InnoDB by
Tom Lane wrote:
It'd be interesting to see what mysql's performance looks like on this
test using innodb tables, which should be compared against fsync = true
... but I don't know how to change it to get all the tables to be
innodb.)
Just a point (I've taught some MySQL courses before,
On Fri, Sep 15, 2006 at 02:11:23AM +0200, Grega Bremec wrote:
Just a point (I've taught some MySQL courses before, sorry 'bout that;
if you're not, I am, sort of :)) - the crash-proof version of
transactional tables in MySQL was supposed to be the Berkeley ones, but
(oh, the irony) they're
Hi
I am trying to run sql-bench against PostgreSQL 8.1.4 on Linux.
Some of the insert tests seems to be ver slow
For example: select_join_in
Are there any tuning parameters that can be changed to speed these queries? Or
are these queries
especially tuned to show MySQL's stgrenths?
All of the tuning parameters would affect all queries
shared buffers, wal buffers, effective cache, to name a few
--dc--
On 13-Sep-06, at 8:24 AM, yoav x wrote:
Hi
I am trying to run sql-bench against PostgreSQL 8.1.4 on Linux.
Some of the insert tests seems to be ver slow
For example:
So why are these queries so slow in PG?
--- Dave Cramer [EMAIL PROTECTED] wrote:
All of the tuning parameters would affect all queries
shared buffers, wal buffers, effective cache, to name a few
--dc--
On 13-Sep-06, at 8:24 AM, yoav x wrote:
Hi
I am trying to run sql-bench
First of all you are going to have to show use what these queries are
exactly, what the machine is you are running on (CPU, memory, and
disk) , and how you have tuned it.
slow is a relative term.. we need information to determine what
slow means.
Dave
On 13-Sep-06, at 8:50 AM, yoav x
The last I checked (years ago), sql-bench was very synthetic (i.e.
reflecting no realistic use case). It's the sort of test suite that's
useful for database developers when testing the effects of a particular
code change or optimization, but not so applicable to real-world uses.
Historically
yoav x [EMAIL PROTECTED] writes:
Are there any tuning parameters that can be changed to speed these
queries? Or are these queries especially tuned to show MySQL's
stgrenths?
The latter. I've ranted about this before --- there are both obvious
and subtle biases in that benchmark. The last
On 9/13/06, Tom Lane [EMAIL PROTECTED] wrote:
IIRC, with these settings PG 8.0 seemed to be about half the speed of
mysql 5.0 w/myisam, which is probably somewhere in the ballpark of the
truth for tests of this nature, ie, single query stream of fairly simple
queries. If you try
Merlin Moncure [EMAIL PROTECTED] writes:
another small aside, I caught the sqlite people actually *detuning*
postgresql for performance by turning stats_command_string=on in
postgresql.conf.
Hm, well, that's not unreasonable if a comparable facility is enabled
in the other databases they're
On Wed, 2006-09-13 at 14:36, Merlin Moncure wrote:
On 9/13/06, Tom Lane [EMAIL PROTECTED] wrote:
IIRC, with these settings PG 8.0 seemed to be about half the speed of
mysql 5.0 w/myisam, which is probably somewhere in the ballpark of the
truth for tests of this nature, ie, single query
Scott Marlowe [EMAIL PROTECTED] writes:
On Wed, 2006-09-13 at 14:36, Merlin Moncure wrote:
another small aside, I caught the sqlite people actually *detuning*
postgresql for performance by turning stats_command_string=on in
postgresql.conf.
They're running autovacuum, which requires that,
On 9/14/06, Scott Marlowe [EMAIL PROTECTED] wrote:
On Wed, 2006-09-13 at 14:36, Merlin Moncure wrote:
another small aside, I caught the sqlite people actually *detuning*
postgresql for performance by turning stats_command_string=on in
postgresql.conf. The way it was portrayed it almost
16 matches
Mail list logo