Re: gprof SELECT COUNT(*) results
От | Qingqing Zhou |
---|---|
Тема | Re: gprof SELECT COUNT(*) results |
Дата | |
Msg-id | Pine.LNX.4.58.0511251247030.26007@eon.cs обсуждение исходный текст |
Ответ на | Re: gprof SELECT COUNT(*) results (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: