Re: database contest results

Jeff Davis wrote:
> On Wed, 2006-08-30 at 00:10 +0200, Andreas Pflug wrote:
>
>>> The author himself said he didn't have time. I didn't mean to be
>>> insulting, and I apologize if I was. 120 versus 3000 seems like the
>>> MySQL entry guys were operating with an entirely separate set of
>>> assumptions, and spent much more time optimizing it and determining the
>>> exact contest requirements.
>>>
>>>
>> Maybe you should have had a look at the article before speculating.
>> Contest requirement was very easy: take the DS sample and make it fast
>> on a given average PC hardware. The MySQL guys were able to take a
>>
>
> Before I posted, I read the English press release along with the thread
> on this list and on pgsql-general, but I don't read German (I only found
> the English translation now). I also read your statement in this thread
> that the MySQL guys tuned the application "to access the database as
> rare [sic] as possible using memcache."
>
> To me, this fact alone means that the author of the PostgreSQL entry
> operated under different assumptions than the author of the MySQL entry.
> Even "simple" contest requirements can be interpreted differently due to
> assumptions. For instance, maybe the author of the PostgreSQL entry made
> the wrong assumptions because, as you put it, the contest was "wrong
> labeled app optimization"?
>
> I stand by my original statement that it was more about understanding
> and adapting to the contest than anything to do with the technical
> database details (like storage engines).
>
The MySQL guys could skip the db adaption completely, and procede to
advanced app side cache techniques. This distorted prerequisites, not
assumptions. It was clear that everybody could use any technique, only
the user interface was fixed. I'm not sure c't tested whether data was
made persistent at all, so a pure in-memory fake maybe would have worked
either (one could argue that using a db without constraints is not far
from that)

Regards,
Andreas