Re: [PERFORM] sql-bench

2006-09-14 Thread Steinar H. Gunderson
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

Re: [PERFORM] sql-bench

2006-09-14 Thread Grega Bremec
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

Re: [PERFORM] sql-bench

2006-09-14 Thread Dave Cramer
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 g

Re: [PERFORM] sql-bench

2006-09-14 Thread Markus Schaber
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 benchmar

Re: [PERFORM] sql-bench

2006-09-13 Thread yoav x
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 paramete

Re: [PERFORM] sql-bench

2006-09-13 Thread Merlin Moncure
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 almos

Re: [PERFORM] sql-bench

2006-09-13 Thread Tom Lane
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

Re: [PERFORM] sql-bench

2006-09-13 Thread Scott Marlowe
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 qu

Re: [PERFORM] sql-bench

2006-09-13 Thread Tom Lane
"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: [PERFORM] sql-bench

2006-09-13 Thread Merlin Moncure
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 concurrent-upd

Re: [PERFORM] sql-bench

2006-09-13 Thread Tom Lane
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

Re: [PERFORM] sql-bench

2006-09-13 Thread Mark Lewis
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 th

Re: [PERFORM] sql-bench

2006-09-13 Thread Dave Cramer
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 wr

Re: [PERFORM] sql-bench

2006-09-13 Thread yoav x
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 s

Re: [PERFORM] sql-bench

2006-09-13 Thread Dave Cramer
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: selec

[PERFORM] sql-bench

2006-09-13 Thread yoav x
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?