Re: gprof SELECT COUNT(*) results

Поиск
Список
Период
Сортировка
От Olivier Thauvin
Тема Re: gprof SELECT COUNT(*) results
Дата
Msg-id 200511251659.31683.olivier.thauvin@aerov.jussieu.fr
обсуждение исходный текст
Ответ на Re: gprof SELECT COUNT(*) results  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: gprof SELECT COUNT(*) results
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: PL/php in pg_pltemplate