To: "Heikki Linnakangas" <heikki@enterprisedb.com>
cc: "Craig Ringer" <craig@postnewspapers.com.au>,
	"pgsql-patches" <pgsql-patches@postgresql.org>
Subject: Re: [PERFORM] Very slow (2 tuples/second) sequential scan after bulk
	insert; speed returns to ~500 tuples/second after commit
In-reply-to: <47D67C3F.1030406@enterprisedb.com> 
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>
Comments: In-reply-to "Heikki Linnakangas" <heikki@enterprisedb.com>
	message dated "Tue, 11 Mar 2008 12:34:07 -0000"
Date: Tue, 11 Mar 2008 17:06:37 -0400
Message-ID: <5827.1205269597@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Heikki Linnakangas" <heikki@enterprisedb.com> writes:
> I initially thought that using a single palloc'd array to hold all the 
> XIDs would introduce a new limit on the number committed 
> subtransactions, thanks to MaxAllocSize, but that's not the case. 
> Without patch, we actually allocate an array like that anyway in 
> xactGetCommittedChildren.

Right.

> Elsewhere in our codebase where we use arrays that are enlarged as 
> needed, we keep track of the "allocated" size and the "used" size of the 
> array separately, and only call repalloc when the array fills up, and 
> repalloc a larger than necessary array when it does. I chose to just 
> call repalloc every time instead, as repalloc is smart enough to fall 
> out quickly if the chunk the allocation was made in is already larger 
> than the new size. There might be some gain avoiding the repeated 
> repalloc calls, but I doubt it's worth the code complexity, and calling 
> repalloc with a larger than necessary size can actually force it to 
> unnecessarily allocate a new, larger chunk instead of reusing the old 
> one. Thoughts on that?

Seems like a pretty bad idea to me, as the behavior you're counting on
only applies to chunks up to 8K or thereabouts.  In a situation where
you are subcommitting lots of XIDs one at a time, this is likely to have
quite awful behavior (or at least, you're at the mercy of the local
malloc library as to how bad it is).  I'd go with the same
double-it-each-time-needed approach we use elsewhere.

			regards, tom lane