Re: database contest results

From: Andreas Pflug
Subject: Re: database contest results
Date: ,
Msg-id: 44F4F1BA.3050209@pse-consulting.de
(view: Whole thread, Raw)
In response to: Re: database contest results  (Jeff Davis)
List: pgsql-advocacy

Tree view

database contest results  (Lukas Kahwe Smith, )
 [ignore this and previous email] Re: database contest results  (Lukas Kahwe Smith, )
 Re: database contest results  (Hans-Juergen Schoenig, )
  Re: database contest results  (Andreas Pflug, )
   Re: database contest results  (Anastasios Hatzis, )
  Re: database contest results  ("Joshua D. Drake", )
  Re: database contest results  (Jeff Davis, )
   Re: database contest results  (Peter Eisentraut, )
    Re: database contest results  (Jeff Davis, )
     Re: database contest results  ("Joshua D. Drake", )
     Re: database contest results  (Jeff Davis, )
     Re: database contest results  (Andreas Pflug, )
      Re: database contest results  (Jeff Davis, )
       Re: database contest results  (Andreas Pflug, )
       Re: database contest results  (mdean, )
        Re: database contest results  (Josh Berkus, )
        Re: database contest results  ("Joshua D. Drake", )
        Re: database contest results  (Brian Hurt, )
 Re: database contest results  (Chris Browne, )
  Re: database contest results  (Andreas Pflug, )

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



pgsql-advocacy by date:

From: Chris Browne
Date:
Subject: Re: database contest results
From: Lukas Kahwe Smith
Date:
Subject: Re: PostgreSQL rebranding