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

From Qingqing Zhou
Subject Re: gprof SELECT COUNT(*) results
Date
Msg-id Pine.LNX.4.58.0511251247030.26007@eon.cs
Whole thread Raw
In response to Re: gprof SELECT COUNT(*) results  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

On Fri, 25 Nov 2005, Tom Lane wrote:
>
> Is that "modern machine" a Xeon by any chance?
>

$#cat /proc/cpuinfo | grep "model name"
model name      : Intel(R) Pentium(R) 4 CPU 2.40GHz

I can find a 4way Xeon (but it is shared by many users):
/h/164/zhouqq#cat /proc/cpuinfo |grep "model name"
model name      : Intel(R) Xeon(TM) CPU 2.40GHz
model name      : Intel(R) Xeon(TM) CPU 2.40GHz
model name      : Intel(R) Xeon(TM) CPU 2.40GHz
model name      : Intel(R) Xeon(TM) CPU 2.40GHz
$/pgsql/src/backend/storage/lmgr#./a.out
Spinlock pair(2648542) duration: 161.785 ms
$/pgsql/src/backend/storage/lmgr#./a.out
Spinlock pair(2648542) duration: 160.661 ms
$/pgsql/src/backend/storage/lmgr#./a.out
Spinlock pair(2648542) duration: 155.505 ms

>
> it now occurs to me that you could still cherry-pick non-corrupt tuples
> with TID-scan queries, so this objection shouldn't be considered fatal.
>

It is great that it is not that difficult to do it! What's more, the
parallel scan will be easier to implement based on page level scan
operators.

Regards,
Qingqing


pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: PL/php in pg_pltemplate
Next
From: Peter Eisentraut
Date:
Subject: Re: PL/php in pg_pltemplate