Received: from localhost (unknown [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id CA8A52E02A3 for ; Wed, 12 Mar 2008 14:53:29 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024) with ESMTP id 99901-01-5 for ; Wed, 12 Mar 2008 14:53:13 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.5 Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.184]) by postgresql.org (Postfix) with ESMTP id 64A5C2E3085 for ; Wed, 12 Mar 2008 14:53:10 -0300 (ADT) Received: by gv-out-0910.google.com with SMTP id y18so866432gvf.7 for ; Wed, 12 Mar 2008 10:53:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=I6uMkapBgJlJ68s1hrCtiHn3SIcGOwsXdrRpJ4BSLjQ=; b=ZhajdocF4KOQgf+o5VjvR/6cHDNxu0RweMljfQ+2k0e/i1cWyzQQ7RLKzndPnz7HRmgzO8XjE27Ch9JnOO695lBTuFcS8jLHlHwe4ycIxBGorCNW0XFgKZsIYtvpISzlVhcRHp3kMJmsNc2TPFpirPGgLP/lIj06H+rAnzrKPFI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=dDX7KeLTdh9+2ROQCIh7bL5CYDKwVEqNktfIZDtqvxpqnvoZ6ee4UPptY2jIhxZncUa9ogduMFIfhDbPaKs5T05puqtOJZsB4TUOFDFhT0xtX/7kMOFhb7Mbl0zZ9kS2yf41QY6wrAq4PrelyYg8IiAryfQSWiltSlzwZwaaN8E= Received: by 10.150.54.6 with SMTP id c6mr4688458yba.77.1205342782939; Wed, 12 Mar 2008 10:26:22 -0700 (PDT) Received: by 10.150.97.21 with HTTP; Wed, 12 Mar 2008 10:26:22 -0700 (PDT) Message-ID: <2e78013d0803121026r227bbebdr5189be193b4a1bf5@mail.gmail.com> Date: Wed, 12 Mar 2008 22:56:22 +0530 From: "Pavan Deolasee" To: "Heikki Linnakangas" Subject: Re: [PERFORM] Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit Cc: "Tom Lane" , "Craig Ringer" , pgsql-patches In-Reply-To: <47D80F5C.2060500@enterprisedb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47D505AF.4040101@postnewspapers.com.au> <47D54DB2.4020405@enterprisedb.com> <24304.1205162440@sss.pgh.pa.us> <47D67C3F.1030406@enterprisedb.com> <5827.1205269597@sss.pgh.pa.us> <47D7DE12.80700@enterprisedb.com> <2e78013d0803120847k2e8afbedrc39e29e5194d3c6e@mail.gmail.com> <19902.1205337439@sss.pgh.pa.us> <2e78013d0803121002o2b7a8531y1553ce66cb6d1537@mail.gmail.com> <47D80F5C.2060500@enterprisedb.com> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200803/197 X-Sequence-Number: 5260 On Wed, Mar 12, 2008 at 10:44 PM, Heikki Linnakangas wrote: > > Imagine that you start a transaction just before transaction > wrap-around, so that the top level XID is 2^31-10. Then you start 20 > subtransactions. What XIDs will they get? Now how would you map those to > a bitmap? > Wait. Subtransaction ids are local to a transaction and always start from 1. See this: /* * reinitialize within-transaction counters */ s->subTransactionId = TopSubTransactionId; currentSubTransactionId = TopSubTransactionId; > > It's not that common to have hundreds of thousands of subtransactions to > begin with.. True. But thats the case we are trying to solve here :-) Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com