Re: How Many Inserts Per Transactions

On 5 Aug 2003 at 12:28, Christopher Browne wrote:
> On Oracle, I have seen performance Suck Badly when using SQL*Load; if
> I grouped too many updates together, it started blowing up the
> "rollback segment," which was a Bad Thing. And in that kind of
> context, there will typically be some "sweet spot" where you want to
> commit transactions before they grow too big.
>
> In contrast, pg_dump/pg_restore puts the load of each table into a
> single COPY statement, so that if there are 15,000,000 entries in the
> table, that gets grouped into a single (rather enormous) transaction.
> And doing things that way presents no particular problem.

Well, psotgresql recycles WAL files and use data files as well to store
uncommitted transaction. Correct me if I am wrong.

Oracle does not do this.

What does this buy? Oracle has constant time commits. I doubt if postgresql has
them with such a design.

For what hassle that is worth, I would buy expand-on-disk as you go approach of
postgresql rather than spending time designing rollback segments for each
application.

It's not nice when customer reports rollback segment overflow. Tablespaces over
file is royal pain when it does not work.

Just a thought..

Bye
Shridhar

--
boss, n: According to the Oxford English Dictionary, in the Middle Ages the
words "boss" and "botch" were largely synonymous, except that boss, in addition
to meaning "a supervisor of workers" also meant "an ornamental stud."