> 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
All,
I have been asked to move this thread to the performance list. Below is
the full discussion to this point.
Doug Knight
WSI Corp
Andover, MA
Forwarded Message
From: Doug Knight <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [HACKERS] Tuning Post
Jakub Ouhrabka <[EMAIL PROTECTED]> 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 relation
Adrian Moisey <[EMAIL PROTECTED]> writes:
>> we've found it: TRUNCATE
> I haven't been following this thread. Can someone please explain to me
> why TRUNCATE causes these spikes?
It's not so much the TRUNCATE as the overhead of broadcasting the
resultant catalog changes to the many hundreds of
> 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
Jakub Ouhrabka <[EMAIL PROTECTED]> writes:
> we've found it: TRUNCATE
Huh. One transaction truncating a dozen tables? That would match the
sinval trace all right ...
> One more question: is it ok to do mass regexp update of pg_proc.prosrc
> changing TRUNCATEs to DELETEs?
You might be throwing
Hi
> I can think of three things that might be producing this:
we've found it: TRUNCATE
I haven't been following this thread. Can someone please explain to me
why TRUNCATE causes these spikes?
--
Adrian Moisey
System Administrator | CareerJunction | Your Future Starts Here.
Web: www.care
Hi Tom,
> I can think of three things that might be producing this:
we've found it: TRUNCATE
We'll try to eliminate use of TRUNCATE and the periodical spikes should
go off. There will still be possibility of spikes because of database
creation etc - we'll try to handle this by issuing trivial
