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

From Rod Taylor
Subject Re: performance of insert/delete/update
Date
Msg-id 1038270003.89124.8.camel@jester
Whole thread Raw
In response to Re: performance of insert/delete/update  (Tim Gardner <tgardner@codeHorse.com>)
Responses Re: performance of insert/delete/update
List pgsql-performance
> 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').

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.

Get yourself a 1GB battery backed ramdisk on it's own scsi chain for WAL
and it'll fly no matter what size of transaction you use ;)

--
Rod Taylor <rbt@rbt.ca>


pgsql-performance by date:

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