Received: from localhost (maia-5.hub.org [200.46.204.182]) by postgresql.org (Postfix) with ESMTP id 5A11F9FB52F for ; Tue, 31 Jul 2007 18:46:36 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.182]) (amavisd-maia, port 10024) with ESMTP id 11862-05 for ; Tue, 31 Jul 2007 18:46:27 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by postgresql.org (Postfix) with ESMTP id 47F009FB4CB for ; Tue, 31 Jul 2007 18:46:31 -0300 (ADT) Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6VLkSqp005140 for ; Tue, 31 Jul 2007 21:46:28 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JM200501C6GJQ00@mail-amer.sun.com> (original mail from J.K.Shah@Sun.COM) for pgsql-performance@postgresql.org; Tue, 31 Jul 2007 15:46:28 -0600 (MDT) Received: from [192.168.1.5] ([76.24.247.188]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JM200FCWCHFVXX1@mail-amer.sun.com>; Tue, 31 Jul 2007 15:46:28 -0600 (MDT) Date: Tue, 31 Jul 2007 17:46:26 -0400 From: "Jignesh K. Shah" Subject: Re: User concurrency thresholding: where do I look? In-reply-to: <200707311433.20568.josh@agliodbs.com> To: josh@agliodbs.com Cc: pgsql-performance@postgresql.org Message-id: <46AFADB2.5070409@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT References: <200707190828.59088.josh@agliodbs.com> <46A90F83.8050401@sun.com> <1185527727.4191.22.camel@ebony.site> <200707311433.20568.josh@agliodbs.com> User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200707/445 X-Sequence-Number: 26129 Yep quite a bit of transactions .. But the piece that's slow is where it is clearing it up in CommitTransaction(). I am not sure of how ProcArrayLock is designed to work and hence not clear what we are seeing is what we expect. Do we have some design doc on ProcArrayLock to understand its purpose? Thanks. Regards, Jignesh Josh Berkus wrote: > Simon, > > >> Well thats pretty weird. That code path clearly only happens once per >> transaction and ought to be fast. The other code paths that take >> ProcArrayLock like TransactionIdIsInProgress() and GetSnapshotData() >> ought to spend more time holding the lock. Presumably you are running >> with a fair number of SERIALIZABLE transactions? >> > > Given that this is TPCC-analog, I'd assume that we are. > > Jignesh? > >