Chris Browne wrote:
> pgsql@j-davis.com (Jeff Davis) writes:
>
>
>> 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).
>>
>
> I wonder if throwing in pgmemcache could have had some similar effects
> on a PostgreSQL-based system...
>
Certainly. I already proposed to use that very latest tuned app and port
it to pgsql, which is just standard porting using PHP. This would make
the app a truely comparable.
Regards,
Andreas
