On 9/27/06, Timwi timwi@gmx.net wrote:
Because this "toy database" is holding up a server that serves millions of page requests per second, quite unlike your own computer which can concentrate all its power on the individual queries you gave it.
* We're not serving millions per second... not to the front ends, and certainly not to the databases. * What else is running on my computer is irrelevant: I provided timings, you can compare the results generated against MySQL yourself. I tried the GFDL_images intersect Living_people query on mysql as an innerjoin, and gave up and aborted it after 5 minutes... the same query takes 3.5 seconds on PostgreSQL. I'm assuming thats because PG can use bitmaps to combine the index outputs from the two halves of the intersection, which is a feature on the roadmap for mysql at least... but 3.5 is the PG number without using array indexing (which as I posted, is much faster). * If you'd like I can setup a parallel load test: the results should be more impressive than my single queries numbers suggested since single queries only use a single CPU. * Because of a number of factors (including support for special indexes) MySQL falls short when compared to other databases systems for everything other than the vanilla insert, update, select queries which it does quite well on... * The end result is that more powerful functionality such as category intersections and full text searching are frustrated by the requirement that we employ additional software outside of the DB then build and maintain glue.