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
|
Список | 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 по дате отправления: