pgsql(at)j-davis(dot)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")
This is Linux country. On a quiet night, you can hear NT re-boot.
In response to
pgsql-advocacy by date
|Next:||From: Lukas Kahwe Smith||Date: 2006-08-30 08:13:56|
|Subject: Re: PostgreSQL rebranding|
|Previous:||From: Joshua D. Drake||Date: 2006-08-30 02:48:58|
|Subject: Re: database contest results|