Re: performance of insert/delete/update

From: Rod Taylor <rbt(at)rbt(dot)ca>
To: Tim Gardner <tgardner(at)codeHorse(dot)com>
Cc: Pgsql Performance <pgsql-performance(at)postgresql(dot)org>, "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>
Subject: Re: performance of insert/delete/update
Date: 2002-11-26 00:20:03
Message-ID: 1038270003.89124.8.camel@jester
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers 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(at)rbt(dot)ca>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message scott.marlowe 2002-11-26 00:23:57 Re: performance of insert/delete/update
Previous Message Tim Gardner 2002-11-25 23:41:53 Re: performance of insert/delete/update

Browse pgsql-performance by date

  From Date Subject
Next Message scott.marlowe 2002-11-26 00:23:57 Re: performance of insert/delete/update
Previous Message Tim Gardner 2002-11-25 23:41:53 Re: performance of insert/delete/update