On Wed, Oct 26, 2011 at 2:47 PM, Aage Johansen <[email protected]> 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]
