Thread

1. MySQL vs PG TPC-H benchmarks

   Nicholas Barr <nicky@chuckie.co.uk> — 2004-04-21T08:31:39Z

   Hi,
   
   Has anyone had a look at:
   
   http://people.ac.upc.es/zgomez/
   
   I realize that MySQL & PG cannot really be compared (especially when you 
   consider the issues that MySQL has with things like data integrity) but 
   still surely PG would perform better than the stats show (i.e. #7 31.28 
   seconds versus 42 minutes!!!).
   
   On a side note it certainly looks like linux kernel 2.6 is quite a bit 
   faster in comparision to 2.4.
   
   Nick
   
   
   
   
   

2. Re: MySQL vs PG TPC-H benchmarks

   Rod Taylor <rbt@rbt.ca> — 2004-04-21T12:19:21Z

   > I realize that MySQL & PG cannot really be compared (especially when you 
   > consider the issues that MySQL has with things like data integrity) but 
   > still surely PG would perform better than the stats show (i.e. #7 31.28 
   > seconds versus 42 minutes!!!).
   
   We know that PostgreSQL 7.5 will perform much better than 7.4 did due to
   the efforts of OSDN and Tom.
   
   I've enquired as to whether they ran ANALYZE after the data load. They
   don't explicitly mention it, and given the mention it took 2.5days to
   load 1GB of data, they're not regular PostgreSQL users.
   
   -- 
   Rod Taylor <rbt [at] rbt [dot] ca>
   
   Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
   PGP Key: http://www.rbt.ca/signature.asc
   

3. Re: MySQL vs PG TPC-H benchmarks

   Rod Taylor <pg@rbt.ca> — 2004-04-21T12:22:29Z

   On Wed, 2004-04-21 at 08:19, Rod Taylor wrote:
   > > I realize that MySQL & PG cannot really be compared (especially when you 
   > > consider the issues that MySQL has with things like data integrity) but 
   > > still surely PG would perform better than the stats show (i.e. #7 31.28 
   > > seconds versus 42 minutes!!!).
   > 
   > We know that PostgreSQL 7.5 will perform much better than 7.4 did due to
   > the efforts of OSDN and Tom.
   
   OSDL not OSDN.
   
   > I've enquired as to whether they ran ANALYZE after the data load. They
   > don't explicitly mention it, and given the mention it took 2.5days to
   > load 1GB of data, they're not regular PostgreSQL users.
   
   
   

4. Re: MySQL vs PG TPC-H benchmarks

   Paul Thomas <paul@tmsl.demon.co.uk> — 2004-04-21T12:55:21Z

   On 21/04/2004 09:31 Nick Barr wrote:
   > Hi,
   > 
   > Has anyone had a look at:
   > 
   > http://people.ac.upc.es/zgomez/
   > 
   > I realize that MySQL & PG cannot really be compared (especially when you 
   > consider the issues that MySQL has with things like data integrity) but 
   > still surely PG would perform better than the stats show (i.e. #7 31.28 
   > seconds versus 42 minutes!!!).
   
   Looks like he's using the default postgresql.conf settings in which case 
   I'm not suprised at pg looking so slow. His stated use of foreign keys 
   invalidates the tests anyway as MyISAM tables don't support FKs so we're 
   probably seeing FK check overheads in pg that are simply ignore by MySQL. 
   In an honest test, MySQL should be reported as failing those tests.
   
   Perhaps one of the advocay team will pick up the batton?
   > 
   > On a side note it certainly looks like linux kernel 2.6 is quite a bit 
   > faster in comparision to 2.4.
   
   Yes, I've seen other benchmarks which also show that.
   
   -- 
   Paul Thomas
   +------------------------------+---------------------------------------------+
   | Thomas Micro Systems Limited | Software Solutions for 
   Business             |
   | Computer Consultants         | 
   http://www.thomas-micro-systems-ltd.co.uk   |
   +------------------------------+---------------------------------------------+
   
   

5. Re: MySQL vs PG TPC-H benchmarks

   Cestmir Hybl <cestmirl@freeside.sk> — 2004-04-21T13:31:02Z

   > Looks like he's using the default postgresql.conf settings in which case
   > I'm not suprised at pg looking so slow.
   
   The question also is, IMHO, why the hell, postgreSQL still comes out of the
   box with so stupid configuration defaults, totally underestimated for todays
   average hardware configuration (1+GHz, 0.5+GB RAM, fast FSB, fast HDD).
   
   It seems to me better strategy to force that 1% of users to "downgrade" cfg.
   than vice-versa.
   
   regards
   ch
   
   
   

6. Re: MySQL vs PG TPC-H benchmarks

   Paul Thomas <paul@tmsl.demon.co.uk> — 2004-04-21T14:08:09Z

   On 21/04/2004 14:31 Cestmir Hybl wrote:
   > > Looks like he's using the default postgresql.conf settings in which
   > case
   > > I'm not suprised at pg looking so slow.
   > 
   > The question also is, IMHO, why the hell, postgreSQL still comes out of
   > the
   > box with so stupid configuration defaults, totally underestimated for
   > todays
   > average hardware configuration (1+GHz, 0.5+GB RAM, fast FSB, fast HDD).
   > 
   > It seems to me better strategy to force that 1% of users to "downgrade"
   > cfg.
   > than vice-versa.
   > 
   > regards
   > ch
   > 
   
   This has been discussed many times before. Check the archives.
   
   -- 
   Paul Thomas
   +------------------------------+---------------------------------------------+
   | Thomas Micro Systems Limited | Software Solutions for 
   Business             |
   | Computer Consultants         | 
   http://www.thomas-micro-systems-ltd.co.uk   |
   +------------------------------+---------------------------------------------+
   
   

7. Re: MySQL vs PG TPC-H benchmarks

   Matthew T. O'Connor <matthew@zeut.net> — 2004-04-21T18:57:16Z

   Paul Thomas wrote:
   
   > Looks like he's using the default postgresql.conf settings in which 
   > case I'm not suprised at pg looking so slow. His stated use of foreign 
   > keys invalidates the tests anyway as MyISAM tables don't support FKs 
   > so we're probably seeing FK check overheads in pg that are simply 
   > ignore by MySQL. In an honest test, MySQL should be reported as 
   > failing those tests.
   
   
   Either failures, or they should not have been using MyISAM, they should 
   have used the table format that supports FK's.  This is just not apples 
   to apples.