Re: performance of insert/delete/update

Поиск
Список
Период
Сортировка
От scott.marlowe
Тема Re: performance of insert/delete/update
Дата
Msg-id Pine.LNX.4.33.0211251725280.8723-100000@css120.ihs.com
обсуждение исходный текст
Ответ на Re: performance of insert/delete/update  (Rod Taylor <rbt@rbt.ca>)
Ответы Re: performance of insert/delete/update  (Rod Taylor <rbt@rbt.ca>)
Re: performance of insert/delete/update  (Andrew Sullivan <andrew@libertyrms.info>)
Список 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 по дате отправления:

Предыдущее
От: "scott.marlowe"
Дата:
Сообщение: Re: performance of insert/delete/update
Следующее
От: Tim Gardner
Дата:
Сообщение: Re: performance of insert/delete/update