Skip site navigation (1) Skip section navigation (2)

Re: gprof SELECT COUNT(*) results

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 (view raw, whole thread or download thread mbox)
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(*)".


In response to


pgsql-hackers by date

Next:From: Christopher Kings-LynneDate: 2005-11-25 02:17:56
Subject: NULL safe equality operator
Previous:From: Simon RiggsDate: 2005-11-24 20:59:19
Subject: Re: gprof SELECT COUNT(*) results

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group