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

Re: profiling connection overhead

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: profiling connection overhead
Date: 2010-11-24 16:20:38
Message-ID: AANLkTinLXOrut35=uNA1fUD7Oo1mVTbO1apCKgJXwhpd@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Wed, Nov 24, 2010 at 10:25 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> The first optimization that occurred to me was "remove the loop
>> altogether".
>
> Or make it execute only in assert-enabled mode, perhaps.
>
> This check had some use back in the bad old days, but the ResourceOwner
> mechanism has probably removed a lot of the argument for it.

Yeah, that's what I was thinking - this could would have been a good
backstop when our cleanup mechanisms were not as robust as they seem
to be today.  But making the check execute only in assert-enabled more
doesn't seem right, since the check actually acts to mask other coding
errors, rather than reveal them.  Maybe we replace the check with one
that only occurs in an Assert-enabled build and just loops through and
does Assert(PrivateRefCount[i] == 0).  I'm not sure exactly where this
gets called in the shutdown sequence, though - is it sensible to
Assert() here?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2010-11-24 16:33:47
Subject: Re: profiling connection overhead
Previous:From: Robert HaasDate: 2010-11-24 16:14:56
Subject: Re: Suggested "easy" TODO: pg_dump --from-list

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