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
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(*)".
In response to
pgsql-hackers by date
|Next:||From: Christopher Kings-Lynne||Date: 2005-11-25 02:17:56|
|Subject: NULL safe equality operator|
|Previous:||From: Simon Riggs||Date: 2005-11-24 20:59:19|
|Subject: Re: gprof SELECT COUNT(*) results|