DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=q2PlFeSMPzn66BZQhhnM3hPHmfiyJ4NHd1zqXUvhr3dld5XL92cGXVkic07FNotbvUZNthnTafmxh5mfYI2k5uYWkvfARXWp/jrRiZrpLAXhcvRmTyYAveLm5IRnF7iVgm61pL0O/J+IiO3JchSQ3qHsgnh06tgj9CDnWPVIwUo=
Message-ID: <dcc563d10801091109kf80ce2dh97b8e4a548f5168f@mail.gmail.com>
Date: Wed, 9 Jan 2008 13:09:20 -0600
From: "Scott Marlowe" <scott.marlowe@gmail.com>
To: "Steve Midgley" <public@misuse.org>
Subject: Re: Re: How to keep at-most N rows per group? periodic DELETEs or
	constraints or..?
Cc: pgsql-sql-owner@postgresql.org, pgsql-sql@postgresql.org
In-Reply-To: <20080109182115.6E39C2E3239@postgresql.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <20080109152431.79AFF2E02F6@postgresql.org>
	<20080109182115.6E39C2E3239@postgresql.org>

On Jan 9, 2008 12:20 PM, Steve Midgley <public@misuse.org> 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.