Skip site navigation (1) Skip section navigation (2)

Re: performance of insert/delete/update

From: Rod Taylor <rbt(at)rbt(dot)ca>
To: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>
Cc: Tim Gardner <tgardner(at)codeHorse(dot)com>,Pgsql Performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: performance of insert/delete/update
Date: 2002-11-26 03:52:51
Message-ID: 1038282771.89124.11.camel@jester (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-performance
On Mon, 2002-11-25 at 19:30, scott.marlowe wrote:
> On 25 Nov 2002, Rod Taylor wrote:
> 
> > > I'm new to postgresql, and as you suggested, this is 
> > > counter-intuitive to me.  I would have thought that having to store 
> > > all the inserts to be able to roll them back would take longer.  Is 
> > > my thinking wrong or not relevant?  Why is this not the case?
> > 
> > Typically that is the case.  But Postgresql switches it around a little
> > bit.  Different trade-offs.  No rollback log, but other processes are
> > forced to go through you're left over garbage (hence 'vacuum').
> 
> Yeah, which means you always need to do a vacuum on a table after a lot of 
> updates/deletes.  And analyze after a lot of inserts/updates/deletes.

A good auto-vacuum daemon will help that out :)  Not really any
different than an OO dbs garbage collection process -- except PGs vacuum
is several orders of magnitude faster.
-- 
Rod Taylor <rbt(at)rbt(dot)ca>


In response to

pgsql-performance by date

Next:From: Ron JohnsonDate: 2002-11-26 04:27:41
Subject: Re: performance of insert/delete/update
Previous:From: Tom LaneDate: 2002-11-26 03:44:29
Subject: Re: performance of insert/delete/update

pgsql-hackers by date

Next:From: Ron JohnsonDate: 2002-11-26 04:27:41
Subject: Re: performance of insert/delete/update
Previous:From: Tom LaneDate: 2002-11-26 03:44:29
Subject: Re: performance of insert/delete/update

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group