Hi Simon, Note that MonetDB/X100 does not have a SQL optimizer, they ran raw hand-coded plans. As a consequence, these comparisons should be taken as an "executor-executor" test and we/you should be sure that the PG planner has generated the best possible plan. That said, we've already done the comparisons internally and they've got a good point to make about L2 cache use and removal of unnecessary abstractions in the executor. We've been aware of this since 2005/6 and have been slowly working these ideas into our/PG executor. Bottom line: it's a good thing to work to get close to the X100/Monet executor with a more general purpose DB. PG is a looong way from being comparable, mostly due to poor L2 D-cache locality and I-cache thrashing in the executor. The only way to cure this is to work on more rows than one at a time. - Luke On 2/4/08 10:37 AM, "Simon Riggs" <simon@xxxxxxxxxxxxxxx> wrote: > Can I ask for some help with benchmarking? > > There are some results here that show PostgreSQL is slower in some cases > than Monet and MySQL. Of course these results were published immediately > prior to 8.2 being released, plus run out-of-the-box, so without even > basic performance tuning. > > Would anybody like to repeat these tests with the latest production > versions of these databases (i.e. with PGSQL 8.3), and with some > sensible tuning settings for the hardware used? It will be useful to get > some blind tests with more sensible settings. > > http://monetdb.cwi.nl/projects/monetdb//SQL/Benchmark/TPCH/ > > Multiple runs from different people/different hardware is useful since > they help to iron-out differences in hardware and test methodology. So > don't worry if you see somebody else doing this also. > > Thanks, ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
