Subject | Re: Transactions and cleaning up of rows after a massive deletion |
---|---|
Author | Aage Johansen |
Post date | 2011-10-26T18:47:52Z |
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.
...
stubs)? 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.
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). 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.
--
Aage J.
<<
...
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)? 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.
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). 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.
--
Aage J.