Re: DELETE performance problem

From: Grzegorz Jaśkiewicz <gryzman(at)gmail(dot)com>
To: Thom Brown <thombrown(at)gmail(dot)com>
Cc: Luca Tettamanti <kronos(dot)it(at)gmail(dot)com>, Jerry Champlin <jchamplin(at)absolute-performance(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: DELETE performance problem
Date: 2009-11-24 15:36:39
Message-ID: 2f4958ff0911240736g7617abe3t49578f25a88eadef@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Tue, Nov 24, 2009 at 3:19 PM, Thom Brown <thombrown(at)gmail(dot)com> wrote:

> 2009/11/24 Luca Tettamanti <kronos(dot)it(at)gmail(dot)com>
>
> On Tue, Nov 24, 2009 at 3:59 PM, Jerry Champlin
>> <jchamplin(at)absolute-performance(dot)com> wrote:
>> > You may want to consider using partitioning. That way you can drop the
>> > appropriate partition and never have the overhead of a delete.
>>
>> Hum, I don't think it's doable in my case; the partitioning is not
>> know a priori. First t1 is fully populated, then the data is loaded
>> and manipulated by my application, the result is stored in t2; only
>> then I want to remove (part of) the data from t1.
>>
>> thanks,
>> Luca
>>
>>
> It's a shame there isn't a LIMIT option on DELETE so this can be done in
> small batches.
>

you sort of can do it, using PK on table as pointer. DELETE FROM foo USING
... etc.
with subquery in using that will limit number of rows ;)

>
> Thom
>

--
GJ

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Matthew Wakeling 2009-11-24 15:41:09 Re: [PERFORM] Strange performance degradation
Previous Message Lorenzo Allegrucci 2009-11-24 15:32:25 Re: [PERFORM] Strange performance degradation