posttМожно ли заключить в одну транзакцию блок,состоящий из 500 000- 1000 000 инсертов и упдейтов? Не приведет ли это к сильному замедлению производителность или к сбою сервера? Это требуется делать для того,чтобы обеспечить целостность данных (либо полное обновление либо никак и повтор процедуры заново).Транзакция оформлена в виде:
BEGIN
INSERT ....
UPDATE ....
COMMIT.
Все дальнейшее мною написаное ИМХО, т.к. практического опыта написания именно такого нету, но:
1. Такое количество операций естественно будет мрачно тормозить из-за как минимум rollback сегмента. Вердикт - попробовать можно, но скорее всего все будет плохо.
2. В 8.1 появился 2-х фазный коммит, и можно себе потихоньку сбрасывать данные, а потом скопом закомитить.
3. В конце концов можно сваять небольшое приложение, для тестирования и просто посмотреть что будет :) и, если не жалко, поместить результаты на форум :)
4. Сделать 2-х файзный коммит самому - т.е. в таблице/таблицах есть признак незавершенности транзакции, данные (эти insert & update) спокойно коммитятся выставляя признак незавершенности, а потом одним/несколькими опретарами update проходится и "докомичевать" все данные убирая признак незавершенности.

Funny_Falcon Andrey Daeron1. Такое количество операций естественно будет мрачно тормозить из-за как минимум rollback сегмента. Вердикт - попробовать можно, но скорее всего все будет плохо.
В PostgreSQL нет rollback сегмента !!!
Хм, действительно нету... зато есть WAL!!! который ничуть не хуже, а во многих случаях лучше :)

Funny_FalconИ если никакая другая транзакция не позариться на апдейченную строчку локов (теоретически) не будет вообще (тормоза будут из-за ввода-вывода, но это лучше чем без транзакции.
Практически же какие-то накладные расходы могут быть. Например, я заметил, что если нужно по какому-либо алгоритму обработать 100000 записей (5-6 апдейтами), то выгоднее разбить их на куски по ~500 записей - быстрее получается, как ни странно.

Это на сколько я понимаю - запись по страницам. Т.е. ПГ сбрасывает более целые страницы на диск.

Funny_Falcon
Кроме того, если другая транзакция тоже захочет изменить строчку (нами изменённую), то лучше, если мы быстрее её отлочим.
Но если на каждую строчку по апдейту - думаю разницы не будет - сразу 100000 в транзакции или по кускам.
Будет. Еще как будет. Каждый commit - это дофига работы, например сбросить ВСЕ изменения в этой транзакции на диск, а потом, бу-а-га-га, дождаться пока тормозной винт таки запишет это физически. И тут будет куча простоев, связанных с IO.
С другой стороны - если долго не комитится, то в WAL все равно будут попадать или старые значения записей, или еще какая байдень. По 16 метров (сегмент) в минуту - наблюдал собственноочно :), и накопится оггроммная куча фигни, с которой что-то нужно делать.
2-х фазный комит может быть поможет.

Вчера написал маленькую тестовую прораммку - 500тыс записей вставляются за 70 секунд, и ни к какому падению ничего не приводят. Так что - если запись не шибко длинная, то фполне можно засунуть в одну транзакцию и надеятся что минут за 5 (300 секунд) все пройдет.
А вообще хоелось бы аффтора послушать, а то все версии и версии...

ЗЫ 2фффф. Подумал и понял, что 2pc совсем не причем, попітался вспомнить зачем я его хотел приплести - и тоже не вспомнил :(