Received: from localhost (unknown [200.46.204.191])
	by postgresql.org (Postfix) with ESMTP id E8A752E01EB
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Tue, 15 Jan 2008 11:46:15 -0400 (AST)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.191]) (amavisd-maia, port 10024)
	with ESMTP id 11109-07 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Tue, 15 Jan 2008 11:46:10 -0400 (AST)
Received: from mx.comgate.cz (mx.comgate.cz [193.165.185.50])
	by postgresql.org (Postfix) with ESMTP id 2A89D2E32DF
	for <pgsql-performance@postgresql.org>;
	Tue, 15 Jan 2008 11:46:10 -0400 (AST)
Received: from alibaba ([127.0.0.1] helo=[10.1.0.53] ident=root)
	by mx.comgate.cz with asmtp (Exim 3.35 #1 (Debian))
	id 1JEnzF-0001Er-00; Tue, 15 Jan 2008 16:46:01 +0100
Message-ID: <478CD535.6030004@comgate.cz>
Date: Tue, 15 Jan 2008 16:45:57 +0100
From: Jakub Ouhrabka <kuba@comgate.cz>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: pgsql-performance@postgresql.org
Subject: Re: Linux/PostgreSQL scalability issue - problem with 8
 cores
References: <flii57$748$1@news.hub.org> <7083.1199379570@sss.pgh.pa.us>
	<477D1D59.7050002@comgate.cz> <4782063C.7070105@comgate.cz>
	<26502.1199745090@sss.pgh.pa.us> <4782AB4D.8010009@comgate.cz>
	<27655.1199750492@sss.pgh.pa.us> <47836A4C.5080707@comgate.cz>
	<10713.1199813111@sss.pgh.pa.us> <47874EE8.2050406@comgate.cz>
	<12997.1200063940@sss.pgh.pa.us> <478B4BB9.4030208@comgate.cz>
	<13894.1200324134@sss.pgh.pa.us> <478CA26E.9040105@comgate.cz>
	<23470.1200410459@sss.pgh.pa.us>
In-Reply-To: <23470.1200410459@sss.pgh.pa.us>
Content-Type: text/plain; charset=windows-1250; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200801/126
X-Sequence-Number: 28365

 > Huh.  One transaction truncating a dozen tables?  That would match the
 > sinval trace all right ...

It should be 4 tables - the shown log looks like there were more truncates?

 > You might be throwing the baby out with the bathwater,
 > performance-wise.

Yes, performance was the initial reason to use truncate instead of 
delete many years ago. But today the truncated tables usualy contain 
exactly one row - quick measurements now show that it's faster to issue 
delete instead of truncate in this case.

Again, many thanks for your invaluable advice!

Kuba