Message-ID: <478CE819.4060409@comgate.cz>
Date: Tue, 15 Jan 2008 18:06:33 +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> <478CD535.6030004@comgate.cz>
	<24676.1200414360@sss.pgh.pa.us>
In-Reply-To: <24676.1200414360@sss.pgh.pa.us>
Content-Type: text/plain; charset=windows-1250; format=flowed
Content-Transfer-Encoding: 7bit

 > Okay, for a table of just a few entries I agree that DELETE is
 > probably better.  But don't forget you're going to need to have those
 > tables vacuumed fairly regularly now, else they'll start to bloat.

I think we'll go with DELETE also for another reason:

Just after we figured out the cause of the spikes we started to 
investigate a long-term issue we had with PostgreSQL: pg_dump of big 
database was blocking some of our applications. And yes, we replaced 
TRUNCATE with DELETE and everything is running as expected.

Looking at the docs now I see there is a new paragraph in 8.3 docs 
mentioning that TRUNCATE is not MVCC-safe and also the blocking issue. 
It's a pity that the warning wasn't there in 7.1 times :-)

Thanks,

Kuba

Tom Lane napsal(a):
> Jakub Ouhrabka <kuba@comgate.cz> writes:
>>>> 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?
> 
> Actually, counting up the entries, there are close to 2 dozen relations
> apparently being truncated in the trace you showed.  But that might be
> only four tables at the user level, since each index on these tables
> would appear separately, and you might have a toast table plus index
> for each one too.  If you want to dig down, the table OIDs are visible
> in the trace, in the messages with type -1:
> 
>>> LOG:  sending inval msg -1 0 30036 0 30700 3218341912
>                                 ^^^^^   ^^^^^
>                                 DBOID   RELOID
> 
> so you could look into pg_class to confirm what's what.
> 
>> 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.
> 
> Okay, for a table of just a few entries I agree that DELETE is probably
> better.  But don't forget you're going to need to have those tables
> vacuumed fairly regularly now, else they'll start to bloat.
> 
> 			regards, tom lane