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
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.
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
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
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
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
-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_
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
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
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
10 matches
Mail list logo