On 9/27/06, Timwi <timwi(a)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.