Re: gprof SELECT COUNT(*) results

On Thu, 24 Nov 2005, Simon Riggs wrote:

>
> Maybe, maybe not. The whole system is designed around high levels of
> concurrent access. If you know for certain you don't ever need that then
> other systems are probably the right choice. Concurrency has a cost and
> a benefit. If you measure the cost, but not the benefit, it will seem
> expensive.
>

Yeah, understood. What I can't understand that in this case why it costs
so much -- without concurrency, the LWLock code path just invloves
spinlock_lock/unlock and serveral simple instructions?

What's more, we can see that for each row, a LWLock pair is invoked. So on
a more aggressive thought, can we change it to page level? I know it is
terriblly difficult since our query processor infrastructure is based on a
single-tuple interface ...

> Your results show you have 2.6m rows, not 260k rows. Yes?

It is 260k since I test each round by 10 "SELECT COUNT(*)".

Regards,
Qingqing