From: | "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at> |
---|---|
To: | "Jean-Paul ARGUDO" <jean-paul(dot)argudo(at)idealx(dot)com>, <pgsql-hackers(at)postgresql(dot)org> |
Cc: | "David BARTH" <dbarth(at)idealx(dot)com>, "Nat MAKAREVITCH" <nat(at)idealx(dot)com>, "Nicolas NICLAUSSE" <nicolas(dot)niclausse(at)idealx(dot)com>, Sébastien DINOT <sebastien(dot)dinot(at)idealx(dot)com> |
Subject: | Re: Survey results on Oracle/M$NT4 to PG72/RH72 migration |
Date: | 2002-03-13 21:30:59 |
Message-ID: | 46C15C39FEB2C44BA555E356FBCD6FA4961D7D@m0114.s-mxs.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 :-)
From | Date | Subject | |
---|---|---|---|
Next Message | Ian Barwick | 2002-03-13 21:33:56 | Re: Archives |
Previous Message | Zeugswetter Andreas SB SD | 2002-03-13 21:19:48 | Re: Survey results on Oracle/M$NT4 to PG72/RH72 migration |