To: Kelly Burkhart <kelly@tradebotsystems.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: 8.x index insert performance 
In-reply-to: <1131655202.7514.46.camel@krb06.tradebot.com> 
References: <6EE64EF3AB31D5448D0007DD34EEB3417DD725@Herge.rcsinc.local>
	<20051031193547.GA3311@mark.mielke.cc>
	<18647.1130790629@sss.pgh.pa.us>
	<1130792391.7026.55.camel@krb06.tradebot.com>
	<19065.1130793527@sss.pgh.pa.us>
	<1130852029.7026.88.camel@krb06.tradebot.com>
	<24845.1130852730@sss.pgh.pa.us>
	<1131655202.7514.46.camel@krb06.tradebot.com>
Comments: In-reply-to Kelly Burkhart <kelly@tradebotsystems.com>
	message dated "Thu, 10 Nov 2005 14:40:02 -0600"
Date: Thu, 10 Nov 2005 17:18:14 -0500
Message-ID: <12266.1131661094@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Kelly Burkhart <kelly@tradebotsystems.com> writes:
> I've finally gotten around to profiling the back end.

Thanks for following up.

The sudden appearance of pg_detoast_datum() in the top ten in the third
profile is suspicious.  I wouldn't expect that to get called at all,
really, during a normal COPY IN process.  The only way I can imagine it
getting called is if you have index entries that require toasting, which
seems a bit unlikely to start happening only after 60 million rows.
Is it possible that the index keys are getting longer and longer as your
test run proceeds?

Could you send me (off list) the complete gprof output files?

			regards, tom lane