On Mon, 2008-02-04 at 10:47 -0800, Luke Lonergan wrote: > 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. If it doesn't then I'd regard that as a performance issue in itself. > 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. You maybe right, but I want to see where it hurts us the most. > The only way to cure this is to work on more rows than one at a time. Do you have any results to show that's true, or are you just referring to the Cray paper? (Which used fixed length tuples and specific vector hardware). (With regard to benchmarks, I'd rather not download Monet at all. Helps avoid legal issues around did-you-look-at-the-code questions.) -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---------------------------(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
