Re: [PERFORMANCE] slow small delete on large table

From: "Ed L(dot)" <pgsql(at)bluepolka(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: [PERFORMANCE] slow small delete on large table
Date: 2004-02-24 18:36:08
Message-ID: 200402241136.08556.pgsql@bluepolka.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Monday February 23 2004 10:23, Tom Lane wrote:
> "Ed L." <pgsql(at)bluepolka(dot)net> writes:
> > If I could say it the way I think for a simple example, it'd be
> > like this:
> >
> > delete from mytable
> > where posteddatetime < now() - '90 days'
> > limit 100;
> >
> > Of course, that's not legal 7.3.4 syntax.
>
> Assuming you have a primary key on the table, consider this:
>
> CREATE TEMP TABLE doomed AS
> SELECT key FROM mytable WHERE posteddatetime < now() - '90 days'
> LIMIT 100;
>
> DELETE FROM mytable WHERE key = doomed.key;
>
> DROP TABLE doomed;
>
> Depending on the size of mytable, you might need an "ANALYZE doomed"
> in there, but I'm suspecting not. A quick experiment suggests that
> you'll get a plan with an inner indexscan on mytable.key, which is
> exactly what you need.

I didn't mention I'd written a trigger to do delete N rows on each new
insert (with a delay governor preventing deletion avalanches). The
approach looks a little heavy to be done from within a trigger with the
response time I need, but I'll try it. Cantchajust toss in that "limit N"
functionality to delete clauses? How hard could that be? ;)

> See also Chris Browne's excellent suggestions nearby, if you are willing
> to make larger readjustments in your thinking...

I did a search for articles by Chris Browne, didn't see one that appeared
relevant. What is the thread subject to which you refer?

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Chris Gamache 2004-02-24 18:58:06 tsearch2 trigger alternative
Previous Message Tom Lane 2004-02-24 18:29:46 Re: Column correlation drifts, index ignored again