Received: from localhost (unknown [200.46.204.184]) by developer.postgresql.org (Postfix) with ESMTP id 3A4012E0091 for ; Sat, 26 Apr 2008 20:20:39 -0300 (ADT) Received: from developer.postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024) with ESMTP id 66412-02 for ; Sat, 26 Apr 2008 20:20:25 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by developer.postgresql.org (Postfix) with ESMTP id ADB6B2E008F for ; Sat, 26 Apr 2008 20:20:31 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id m3QNKT62011002; Sat, 26 Apr 2008 19:20:29 -0400 (EDT) To: Robert Treat cc: pgsql-performance@postgresql.org, Alvaro Herrera Subject: Re: Re: [HACKERS] [COMMITTERS] pgsql: Fix TransactionIdIsCurrentTransactionId() to use binary search In-reply-to: <200804261420.16064.xzilla@users.sourceforge.net> References: <20080317021856.0D2D37558DC@cvs.postgresql.org> <200804260910.55203.xzilla@users.sourceforge.net> <13180.1209230804@sss.pgh.pa.us> <200804261420.16064.xzilla@users.sourceforge.net> Comments: In-reply-to Robert Treat message dated "Sat, 26 Apr 2008 14:20:15 -0400" Date: Sat, 26 Apr 2008 19:20:29 -0400 Message-ID: <11001.1209252029@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200804/379 X-Sequence-Number: 29872 Robert Treat writes: > On Saturday 26 April 2008 13:26, Tom Lane wrote: >> Oh, you failed to state that the dtrace output was post-patch. You need >> to show *pre* patch dtrace output if you want us to think it relevant. > Please read up-thread. Sorry, I'd forgotten your previous post. I poked around for calls to TransactionIdIsCurrentTransactionId that are in current code and weren't in 8.1. I found these: src/backend/commands/analyze.c: 965: if (TransactionIdIsCurrentTransactionId(HeapTupleHeaderGetXmin(targtuple.t_data))) src/backend/commands/analyze.c: 984: if (TransactionIdIsCurrentTransactionId(HeapTupleHeaderGetXmax(targtuple.t_data))) src/backend/commands/cluster.c: 803: if (!TransactionIdIsCurrentTransactionId( src/backend/commands/cluster.c: 816: if (!TransactionIdIsCurrentTransactionId( src/backend/storage/ipc/procarray.c: 374: if (TransactionIdIsCurrentTransactionId(xid)) src/backend/utils/time/combocid.c: 108: Assert(TransactionIdIsCurrentTransactionId(HeapTupleHeaderGetXmin(tup))); src/backend/utils/time/combocid.c: 123: Assert(TransactionIdIsCurrentTransactionId(HeapTupleHeaderGetXmax(tup))); src/backend/utils/time/combocid.c: 156: TransactionIdIsCurrentTransactionId(HeapTupleHeaderGetXmin(tup))) The ANALYZE and CLUSTER calls are not likely to be your issue, but the one in HeapTupleHeaderAdjustCmax could get called a lot, and the one in TransactionIdIsInProgress definitely will get called a lot. Neither of those calls existed in 8.2. So I think that explains why TransactionIdIsCurrentTransactionId has become more performance-critical in 8.3 than it was before. Will apply the back-patch. regards, tom lane