Re: performance of insert/delete/update - Mailing list pgsql-performance

From scott.marlowe
Subject Re: performance of insert/delete/update
Date
Msg-id Pine.LNX.4.33.0211251725280.8723-100000@css120.ihs.com
Whole thread Raw
In response to Re: performance of insert/delete/update  (Rod Taylor <rbt@rbt.ca>)
Responses Re: performance of insert/delete/update  (Rod Taylor <rbt@rbt.ca>)
Re: performance of insert/delete/update  (Andrew Sullivan <andrew@libertyrms.info>)
List pgsql-performance
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.


pgsql-performance by date:

Previous
From: "scott.marlowe"
Date:
Subject: Re: performance of insert/delete/update
Next
From: Tim Gardner
Date:
Subject: Re: performance of insert/delete/update