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

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 :-)

Responses

Browse pgsql-hackers by date

  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