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...
--
output = reverse("gro.gultn" "@" "enworbbc")
http://www3.sympatico.ca/cbbrowne/x.html
This is Linux country. On a quiet night, you can hear NT re-boot.
