Date: Mon, 19 Jun 2006 13:13:27 -0400
From: Daniel CAUNE <d.caune@free.fr>
Subject: Re: keeping last 30 entries of a log table
In-reply-to: 
 <Pine.LNX.4.64.0606190915540.27250@glacier.frostconsultingllc.com>
To: 'Jeff Frost' <jeff@frostconsultingllc.com>
Cc: pgsql-sql@postgresql.org
Message-id: <0J1400MJFAIHSME0@VL-MH-MR002.ip.videotron.ca>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 7BIT
Thread-index: AcaTu/Lm++7LJ9CQRQ25vUOQ0a7RYwABzs8A


> >> insert into log (account_id, message) values (1, 'this is a test);
> >> delete from log where account_id = 1 and id not in ( select id from log
> >>    where account_id = 1 order by timestamp desc limit 30);
> >>
> >> I'm wondering if there is a more performance oriented method of doing
> the
> >> delete that I'm not thinking of.
> >>
> >
> > Depending on whether id is a kind of auto-incremented column that never
> cycles, I would suggest something like:
> >
> > DELETE FROM log
> >  WHERE account_id = 1
> >    AND id < (
> >      SELECT MIN(id)
> >        FROM log
> >        WHERE account_id = 1
> >        ORDER BY timestamp DESC
> >        LIMIT 30);
> >
> > I think there will be a performance difference with your method when the
> number of records to be deleted is huge.
> 
> Thanks Daniel, I'll try and benchmark them both and see if < turns out to
> be
> faster than NOT IN.  I guess there's no way to get around the subselect
> though.
> 

Column id should be indexed indeed.  Anyway, I'm not sure about any performance improvement using that last method, as the most consuming operation might be the DELETE operation, not really the SELECT operation, when dealing with a huge volume of data.


--
Daniel