Re: Survey results on Oracle/M$NT4 to PG72/RH72 migration - Mailing list pgsql-hackers

From Zeugswetter Andreas SB SD
Subject Re: Survey results on Oracle/M$NT4 to PG72/RH72 migration
Date
Msg-id 46C15C39FEB2C44BA555E356FBCD6FA4961D7D@m0114.s-mxs.net
Whole thread Raw
In response to Survey results on Oracle/M$NT4 to PG72/RH72 migration  (Jean-Paul ARGUDO <jean-paul.argudo@idealx.com>)
Responses Re: Survey results on Oracle/M$NT4 to PG72/RH72 migration  (Hannu Krosing <hannu@krosing.net>)
List 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 by date:

Previous
From: Ian Barwick
Date:
Subject: Re: Archives
Next
From: Vince Vielhaber
Date:
Subject: insert statements