Re: gprof SELECT COUNT(*) results - Mailing list pgsql-hackers

From Olivier Thauvin
Subject Re: gprof SELECT COUNT(*) results
Date
Msg-id 200511251659.31683.olivier.thauvin@aerov.jussieu.fr
Whole thread Raw
In response to Re: gprof SELECT COUNT(*) results  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Le Vendredi 25 Novembre 2005 16:20, Tom Lane a écrit :
> Qingqing Zhou <zhouqq@cs.toronto.edu> writes:
> > I can see your computer is really slow, so my theory is that since it is
> > easy to hold a running-slowly horse than a fast one, so my spinlock on a
> > 2.4G modern machine should takes relatively longer time to get effective.
> > Just kidding.
>
> Is that "modern machine" a Xeon by any chance?  We know that Xeons have
> fairly awful concurrent performance, and the long latency for bus lock
> instructions may well be the reason why.  FWIW, the numbers I showed
> last night were for an HPPA machine, which I used just because I chanced
> to have CVS tip already built for profiling on it.  I've since
> reproduced the test on a spiffy new dual Xeon that Red Hat just bought
> me :-) ... and I get similar numbers to yours.  It'd be interesting to
> see the results from an SMP Opteron, if anyone's got one handy.

Is that what you're looking for ?

[thauvin@samsufi ~]$ egrep "(model name|MHz)" /proc/cpuinfo
model name      : AMD Opteron(tm) Processor 250
cpu MHz         : 2391.040
model name      : AMD Opteron(tm) Processor 250
cpu MHz         : 2391.040

$ cat /etc/mandrake-release
Mandrakelinux release 10.1 (Community) for x86_64

I can try to backport Postgresql 8.1.0 rpms from developement tree on mandriva
10.1, install and run some test if you're really interested.


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: gprof SELECT COUNT(*) results
Next
From: Peter Eisentraut
Date:
Subject: Re: PL/php in pg_pltemplate