On Thu, Mar 19, 2009 at 4:11 PM, Will Rutherdale (rutherw) <rutherw@xxxxxxxxx> wrote: > I am already aware of this issue, and am preparing to explain it to people. Well, keep in mind that MOST people are gonna wave you off, and figure it doesn't matter that much. Lots of developers are pretty cavalier with their user's data. Now, if the data is easily replaceable, then fine. Put a price on the data. Pay attention to that price, and don't underestimate it. It's usually the most expensive thing on a db server. > Having said that, if it were possible to set up a reasonably average > database, with a test application that hits it with a reasonable mix of > select, insert, and update operations, and run it one at a time against > different RDBMSs on the same machine, then it might yield some simple > numbers that could be quoted to people in case they asked. But will you be comparing apples to apples. MySQL plays fast and loose with data integrity (with myisam tables). So at least make sure you're comparing what you need to compare. If data integrity is important, you need to use innodb. If it isn't, then just use flat files. > The goal is not to absolutely determine which is fastest in the made-up > scenario, I don’t think anyone cares. However it would be interesting to > see if the different RDBMSs came in within a reasonable percentage of each > other. But again, if you're comparing a Go kart to a pickup truck, you need to know that's what you're doing. The abstract numbers mean little outside of that fact. > An analogy would be BogoMIPS. Nobody takes it that seriously because they > know there are numerous factors that affect how a machine runs under > different applications. But as a quick sanity check BogoMIPS can be useful > at times. Sorry, but I respectfully disagree. Bogomips has the word bogo in it on purpose. It means, literally, almost nothing useful to the user. Any modern db is fast enough for the kind of low level stuff you've mentioned so far. Until you have a better idea what your application(s) might look like, it's hard to offer any real advice besides "avoid myisam" -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
