Re: performance of insert/delete/update

Поиск
Список
Период
Сортировка
Искать
От
Tim Gardner
Тема
Re: performance of insert/delete/update
Дата
Msg-id
p05111b0dba0864e04ba2@[192.168.1.4]
Ответ на
Список
Дерево обсуждения
Re: [HACKERS] Realtime VACUUM, was: performance of insert/delete/update Jim Beckstrom <jrbeckstrom@sbcglobal.net>
Re: [HACKERS] Realtime VACUUM, was: performance of "scott.marlowe" <scott.marlowe@ihs.com>
>The funny thing it, they've often avoided transactions because they
>figured they'd be slower than just inserting the rows, and you kinda have
>to make them sit down first before you show them the performance increase
>from putting all those inserts into a single transaction.
>
>No offense meant, really.  It's just that you seemed to really doubt that
>putting things into one transaction helped, and putting things into one
>big transaction if like the very first postgresql lesson a lot of
>newcomers learn. :-)

Scott,

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?

Thanks,
Tim
В списке pgsql-performance по дате отправления
От: scott.marlowe
Дата:
От: Rod Taylor
Дата:
FAQ