Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id CDF6C2E036E for ; Tue, 11 Mar 2008 10:13:19 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 90695-08 for ; Tue, 11 Mar 2008 10:13:05 -0300 (ADT) X-Greylist: delayed 00:06:27.679584 by SQLgrey-1.7.5 Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.190]) by postgresql.org (Postfix) with ESMTP id 3DE9C2E0366 for ; Tue, 11 Mar 2008 10:13:04 -0300 (ADT) Received: by rn-out-0910.google.com with SMTP id e11so1321448rng.17 for ; Tue, 11 Mar 2008 06:13:02 -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=U8EOCdLyOw7nXNvYBAhinF/5JsA6Oh/wFjCW2kP3bpw=; b=Wxd+QPfItwVD64Eq2+tUR/PjYNxc8GoSo1TNZ1LdxogsNf1dkM4KDuPSE+xWbYK5pJ33Dxz/EiLCbRO3xztzf5hRodFwJRNDP1quo+pkN/XLGUvEf+dCwaRUkMrXrcQ1UvtwlXoctBjZ/uGjjPRkc+WMcAziqoSxUvUj/gBhghg= 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=SzDomoO+EFbpEspkABxxhStErnSiC5K2arQrcpB4IU8v52lHpOKsCibzjboStV4bLNhHkDx4saEyQTA73AQizFV606rnFUkWB+c1yR/oVD1lwU91+5DZcp//buRqB3ayFBTvV+ZGxikgyvZp9XCju6CidwdavWQb8+XmwqSBfb8= Received: by 10.151.157.8 with SMTP id j8mr3643413ybo.86.1205240793846; Tue, 11 Mar 2008 06:06:33 -0700 (PDT) Received: by 10.150.97.21 with HTTP; Tue, 11 Mar 2008 06:06:33 -0700 (PDT) Message-ID: <2e78013d0803110606hb0eaa2aq1784608cf4c7026c@mail.gmail.com> Date: Tue, 11 Mar 2008 18:36:33 +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: <47D67C3F.1030406@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> <47D5150C.8090802@enterprisedb.com> <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> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200803/152 X-Sequence-Number: 5215 On Tue, Mar 11, 2008 at 6:04 PM, Heikki Linnakangas wrote: > (moved to pgsql-patches, as there's a patch attached) > > > I couldn't let this case go, so I wrote a patch. I replaced the linked > list with an array that's enlarged at AtSubCommit_childXids when necessary. > We can replace the array of xids with an array of flags where i'th flag is set to true if the corresponding subtransaction is committed. This would make lookup O(1) operation. Of course, the downside is when the array is sparse. Or we can switch to flag based representation once the array size grows beyond a limit. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com