From: | Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: gprof SELECT COUNT(*) results |
Date: | 2005-11-24 21:27:05 |
Message-ID: | Pine.LNX.4.58.0511241618290.16035@josh.db |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Kings-Lynne | 2005-11-25 02:17:56 | NULL safe equality operator |
Previous Message | Simon Riggs | 2005-11-24 20:59:19 | Re: gprof SELECT COUNT(*) results |