Re: performance of insert/delete/update

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.

> It's still kinda slow with hundreds of connections (as compared to
> Oracle) -- but close enough that a license fee -> hardware purchase
> funds transfer more than makes up for it.

Ain't it amazing how much hardware a typical Oracle license can buy? ;^)

Heck, even the license cost MS-SQL server is enough to buy a nice quad 
Xeon with all the trimmings nowadays.  Then you can probably still have 
enough left over for one of the pgsql developers to fly out and train your 
folks on it.