On Wed, Oct 26, 2011 at 2:47 PM, Aage Johansen <aagjohan@...> wrote:

> Thomas wrote:
> <<
> ...
> Perhaps your read process couldn't delete the record but mark it with a
> flag and a cleanup process scheduled e.g. in the night deletes the
> marked records followed by initiating a manual SELECT COUNT(*) on that
> table in case of co-operative garbage collection.
> ...
> >>
>
> Will updating (mark with a flag) create record versions (and
> stubs)?

Marking the record with a flag will create a version. Deleting that version
will create a stub.

> These will need to be taken care of later, so maybe not much
> time will be saved (relative to GC). Maybe just moved to another
> point in time.
>

Yup. Or, in the worst case, creating the problem when it occurs and then
the same sized problem later.

> A "select count(*)" can be run with the same WHERE clause as in the
> update (if at all practicable). Unless the "where" is too
> complicated it might save some time compared to a full GC.
> It could be a good thing for the updating program itself to do the
> select (after committing).

Only if it's sure that it's the oldest transaction in the system.

> Get rid of the garbage - don't leave it
> as a surprise for an unsuspecting user at a later time. YMMV, no
> solution is perfect in every situation.
>

So sadly true.

Good luck,

Ann


[Non-text portions of this message have been removed]