Received: from localhost (unknown [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id 481682E020D for ; Wed, 12 Mar 2008 14:03:00 -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 67544-07-2 for ; Wed, 12 Mar 2008 14:02:38 -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.188]) by postgresql.org (Postfix) with ESMTP id 9EC2F2E007A for ; Wed, 12 Mar 2008 14:02:39 -0300 (ADT) Received: by gv-out-0910.google.com with SMTP id y18so853506gvf.7 for ; Wed, 12 Mar 2008 10:02:38 -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=HOPq0Is8jWQzPjv8LfB/CkZ0akGIUKRHoclDbC18eCY=; b=JINoLxoVJXGPTffFVcnz1VNsT7O73a8zoWT7w7yNQZXdVPKLwNiFMDtQit0jCPMa6ins2v8z/0DDZp3T1Z/OoCd2i49Bd3nbejd0S1BPVKN2xNykLNYB7Up1JejRB9omXpiHPRoN+ShrFHuFEKs0qkcuvXcbv611ch4ikOyzZ98= 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=vMBh3Lx+l9uip0L0EfC1zD0dasuOLTUs8ZGdsXwujIjeEA0wToKyEdHaG2LqbNtCkiI+CUngjLplkoO9tVE6QVSzGEHiVpDWCqOwpdJCm9wA1JkYB+iBMNq1K7d0SFhqWPXWCZ8Eci8cV+J1adzsATirvI03ZAsbs/dZh6xzWnw= Received: by 10.150.57.5 with SMTP id f5mr4672334yba.71.1205341357238; Wed, 12 Mar 2008 10:02:37 -0700 (PDT) Received: by 10.150.97.21 with HTTP; Wed, 12 Mar 2008 10:02:37 -0700 (PDT) Message-ID: <2e78013d0803121002o2b7a8531y1553ce66cb6d1537@mail.gmail.com> Date: Wed, 12 Mar 2008 22:32:37 +0530 From: "Pavan Deolasee" To: "Tom Lane" Subject: Re: [PERFORM] Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit Cc: "Heikki Linnakangas" , "Craig Ringer" , pgsql-patches In-Reply-To: <19902.1205337439@sss.pgh.pa.us> 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> <23588.1205159638@sss.pgh.pa.us> <47D54A47.3030608@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> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200803/192 X-Sequence-Number: 5255 On Wed, Mar 12, 2008 at 9:27 PM, Tom Lane wrote: > > I didn't like it; it seemed overly complicated (consider dealing with > XID wraparound), We are talking about subtransactions here. I don't think we support subtransaction wrap-around, do we ? > and it would have problems with a slow transaction > generating a sparse set of subtransaction XIDs. I agree thats the worst case. But is that common ? Thats what I was thinking when I proposed the alternate solution. I thought that can happen only if most of the subtransactions abort, which again I thought is not a normal case. But frankly I am not sure if my assumption is correct. > I think getting rid of > the linear search will be enough to fix the performance problem. > I wonder if a skewed binary search would help more ? For example, if we know that the range of xids stored in the array is 1 to 1000 and if we are searching for a number closer to 1000, we can break the array into parts instead of equal parts and then search. Well, may be I making simple things complicated ;-) Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com