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>
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 |
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 |