On Jan 9, 2008 12:20 PM, Steve Midgley <[EMAIL PROTECTED]> wrote: > This is kludgy but you would have some kind of random number test at > the start of the trigger - if it evals true once per every ten calls to > the trigger (say), you'd cut your delete statements execs by about 10x > and still periodically truncate every set of user rows fairly often. On > average you'd have ~55 rows per user, never less than 50 and a few > outliers with 60 or 70 rows before they get trimmed back down to 50.. > Seems more reliable than a cron job, and solves your problem of an ever > growing table? You could adjust the random number test easily if you > change your mind of the balance of size of table vs. # of delete > statements down the road.
And, if you always through a limit 50 on the end of queries that retrieve data, you could let it grow quite a bit more than 60 or 70... Say 200. Then you could have it so that the random chopper function only gets kicked off every 100th or so time. ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
