Re: Survey results on Oracle/M$NT4 to PG72/RH72 migration

Поиск
Список
Период
Сортировка
От Zeugswetter Andreas SB SD
Тема Re: Survey results on Oracle/M$NT4 to PG72/RH72 migration
Дата
Msg-id 46C15C39FEB2C44BA555E356FBCD6FA4961D7D@m0114.s-mxs.net
обсуждение исходный текст
Ответ на Survey results on Oracle/M$NT4 to PG72/RH72 migration  (Jean-Paul ARGUDO <jean-paul.argudo@idealx.com>)
Ответы Re: Survey results on Oracle/M$NT4 to PG72/RH72 migration  (Hannu Krosing <hannu@krosing.net>)
Список pgsql-hackers
> So this finaly makes the batch work taking 300% the time Oracle needs.
> We clearly see our ECPG programs waits for PostgreSQL in the functions
> were CURSORs are opened. Then, we know the problem is not in ECPG but in
> PG backend.

> This is unaceptable for our customer. Many batches are launched during
> the night and have to be completed in 5h (between 0h and 5h). With a
> ratio of 3, this is not worth think about migration anymore :-(

So why exactly can you not simply do the whole batch in one transaction ?

Unless you need to run concurrent vacuums, or are low on disk space, or need
to concurrently update the affected rows (thus fear deadlocks or locking out
interactive clients that update), there is no need to do frequent commits in
PostgreSQL for batch work.

Andreas

PS: I know that coming from other DB's one fears "snapshot too old", filling
rollback segments, or other "deficiencies" like long transaction aborted :-)


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Ian Barwick
Дата:
Сообщение: Re: Archives
Следующее
От: Vince Vielhaber
Дата:
Сообщение: insert statements