At 12:02 PM 7/06/2004 +0000, you wrote:

> > Apparently it does. :-) That is, if you plan to write an
>application that
> > just updates the same record thousands and thousands of times.
> >
> > On the other hand, if your application updates multiple records in
> > different tables, then garbage collection will clean up the old record
> > versions and you won't see this slowdown you get by hammering the same
> > record over and over.
> >
> > /heLen
>
>In fact, the actual application executes many different queries; among
>them, there is some UPDATE queries, on a table having few records:
>
>
>EVENTSUMMARY (140)
> Primary pointer page: 254, Index root page: 255
> Average record length: 68.75, total records: 12
> Average version length: 22.53, total versions: 1461, max versions: 247
>
>I noticed that the number of versions is only growing and never goes
>down, that is, the (old) versions are never garbage collected. Hence
>the test program I wrote.
>
>I wondered for what reason the garbage collector does not start, given
>that I have just one connection, and that I commit all transactions.

What is this commit_transaction statement? Is it from IBPP? I'd want to
find out whether it is a commit with RETAIN. In this case, garbage
collection never happens until the connection closes, because the same
transaction stays open and therefore "active" and "interesting". Old
record versions from active and interesting transactions don't get
garbage-collected.

This type of updating - where users are hitting the same few rows
repeatedly - needs a wham-wham-bam approach: explicit hard commit as soon
as they post; immediate rollback if they except.

/heLen