Re: [PERFORM] DELETE performance problem

2009-11-25 Thread Grzegorz Jaśkiewicz
On Wed, Nov 25, 2009 at 4:13 PM, Luca Tettamanti wrote: > > > DELETE FROM t1 WHERE EXISTS (SELECT 1 FROM t2 WHERE t1.annotation_id = > t2.annotation_id) > > performs event better: > > Seq Scan on t1 (cost=0.00..170388415.89 rows=22937406 width=6) (actual > time=272.625..561241.294 rows=26185953

Re: [PERFORM] DELETE performance problem

2009-11-25 Thread Luca Tettamanti
On Wed, Nov 25, 2009 at 04:22:47PM +0100, marcin mank wrote: > On Tue, Nov 24, 2009 at 2:37 PM, Luca Tettamanti wrote: > >         ->  HashAggregate  (cost=1031681.15..1033497.20 rows=181605 > > width=8) (a > > ctual time=571807.575..610178.552 rows=26185953 loops=1) > > > This is Your problem.

Re: [PERFORM] DELETE performance problem

2009-11-25 Thread marcin mank
On Tue, Nov 24, 2009 at 2:37 PM, Luca Tettamanti wrote: >         ->  HashAggregate  (cost=1031681.15..1033497.20 rows=181605 width=8) > (a > ctual time=571807.575..610178.552 rows=26185953 loops=1) This is Your problem. The system`s estimate for the number of distinct annotation_ids in t2 is w

Re: [PERFORM] DELETE performance problem

2009-11-24 Thread Kris Kewley
e: 303-588-2547 -Original Message- From: pgsql-performance-ow...@postgresql.org [mailto:pgsql-performance-ow...@postgresql.org] On Behalf Of Luca Tettamanti Sent: Tuesday, November 24, 2009 6:37 AM To: pgsql-performance@postgresql.org Subject: [PERFORM] DELETE performance problem Hello, I&#x

Re: [PERFORM] DELETE performance problem

2009-11-24 Thread Alan Hodgson
On Tuesday 24 November 2009, Thom Brown wrote: > > It's a shame there isn't a LIMIT option on DELETE so this can be done in > small batches. delete from table where pk in (select pk from table where delete_condition limit X); -- "No animals were harmed in the recording of this episode. We tri

Re: [PERFORM] DELETE performance problem

2009-11-24 Thread Grzegorz Jaśkiewicz
On Tue, Nov 24, 2009 at 3:19 PM, Thom Brown wrote: > 2009/11/24 Luca Tettamanti > > On Tue, Nov 24, 2009 at 3:59 PM, Jerry Champlin >> wrote: >> > You may want to consider using partitioning. That way you can drop the >> > appropriate partition and never have the overhead of a delete. >> >> Hu

Re: [PERFORM] DELETE performance problem

2009-11-24 Thread Jerry Champlin
-ow...@postgresql.org] On Behalf Of Luca Tettamanti Sent: Tuesday, November 24, 2009 6:37 AM To: pgsql-performance@postgresql.org Subject: [PERFORM] DELETE performance problem Hello, I've run in a severe performance problem with the following statement: DELETE FROM t1 WHERE t1.annotation_

Re: [PERFORM] DELETE performance problem

2009-11-24 Thread Thom Brown
2009/11/24 Luca Tettamanti > On Tue, Nov 24, 2009 at 3:59 PM, Jerry Champlin > 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

Re: [PERFORM] DELETE performance problem

2009-11-24 Thread Luca Tettamanti
On Tue, Nov 24, 2009 at 3:59 PM, Jerry Champlin 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 pop

[PERFORM] DELETE performance problem

2009-11-24 Thread Luca Tettamanti
Hello, I've run in a severe performance problem with the following statement: DELETE FROM t1 WHERE t1.annotation_id IN ( SELECT t2.annotation_id FROM t2) t1 contains about 48M record (table size is 5.8GB), while t2 contains about 60M record (total size 8.6GB). annotation_id is the PK in t