On Sat, Jul 29, 2006 at 08:43:49AM -0700, Joshua D. Drake wrote:
> Jochem van Dieten wrote:
> >Tweakers.net has done a database performance test between a Sun T2000 (8
> >core T1) and a Sun X4200 (2 dual core Opteron 280). The database
> >benchmark is developed inhouse and represents the average query pattern
> >from their website. It is MySQL centric because Tweakers.net runs on
> >MySQL, but Arjen van der Meijden has ported it to PostgreSQL and has
> >done basic optimizations like adding indexes.
> >
> >Arjen wrote about some of the preliminary results previously in
> >http://archives.postgresql.org/pgsql...6/msg00358.php
> >but the article has now been published http://tweakers.net/reviews/633/7
> >This is all the more impressive if you scroll down and look at the
> >behaviour of MySQL (after tweaking by both MySQL AB and Sun).
>
> I would love to get my hands on that postgresql version and see how much
> farther it could be optimized.

I'd love to get an english translation that we could use for PR.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

On 1-8-2006 19:26, Jim C. Nasby wrote:
> On Sat, Jul 29, 2006 at 08:43:49AM -0700, Joshua D. Drake wrote:
>
> I'd love to get an english translation that we could use for PR.

Actually, we have an english version of the Socket F follow-up.
http://tweakers.net/reviews/638 which basically displays the same
results for Postgres vs MySQL.
If and when a translation of the other article arrives, I don't know.
Other follow-up stories will follow as well, whether and how soon those
will be translated, I also don't know. We are actually pretty interested
in doing so, but its a lot of work to translate correctly

Best regards,

Arjen

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Hi, Arjen,

Arjen van der Meijden wrote:

> It was the 8core version with 16GB memory... but actually that's just
> overkill, the active portions of the database easily fits in 8GB and a
> test on another machine with just 2GB didn't even show that much
> improvements when going to 7GB (6x1G, 2x 512M), it was mostly in the
> range of 10% improvement or less.

I'd be interested in the commit_siblings and commit_delay settings,
tuning them could give a high increase on throughput for highly
concurrent insert/update workloads, at the cost of latency (and thus
worse results for low concurrency situations).

Different fsync method settings can also make a difference (I presume
that syncing was enabled).

HTH,
Markus


--
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf. | Software Development GIS

Fight against software patents in EU! www.ffii.org www.nosoftwarepatents.org

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Hi Markus,

As said, our environment really was a read-mostly one. So we didn't do
much inserts/updates and thus spent no time tuning those values and left
them as default settings.

Best regards,

Arjen

Markus Schaber wrote:
> Hi, Arjen,
>
> Arjen van der Meijden wrote:
>
>> It was the 8core version with 16GB memory... but actually that's just
>> overkill, the active portions of the database easily fits in 8GB and a
>> test on another machine with just 2GB didn't even show that much
>> improvements when going to 7GB (6x1G, 2x 512M), it was mostly in the
>> range of 10% improvement or less.
>
> I'd be interested in the commit_siblings and commit_delay settings,
> tuning them could give a high increase on throughput for highly
> concurrent insert/update workloads, at the cost of latency (and thus
> worse results for low concurrency situations).
>
> Different fsync method settings can also make a difference (I presume
> that syncing was enabled).
>
> HTH,
> Markus
>
>

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq