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 ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
