Re: Bad performing DELETE

=?iso-8859-1?Q?Hans=2DJ=FCrgen=20Sch=F6nig?= <hs(at)cybertec(dot)at> writes:
> I have two tables: t_haus is about 1400 row and t_host has 364000 entries.
> Both tables are indexed on edvnr. I did a vacuum on my db and all indices
> are rebuild.
> I want to delete all Entries in t_haus where a row can be found in t_host.
> When using "delete from t_haus where t_haus.edvnr=t_host.edvnr; " the
> database performs extremely bad.

> explain delete from t_haus where t_haus.edvnr=t_host.edvnr;
> NOTICE: QUERY PLAN:
> Merge Join (cost=52178.53..56754.63 rows=6299767 width=14)
> -> Sort (cost=52038.25..52038.25 rows=364359 width=4)
> -> Seq Scan on t_host (cost=0.00..11700.59 rows=364359 width=4)
> -> Sort (cost=140.27..140.27 rows=1729 width=10)
> -> Seq Scan on t_haus (cost=0.00..47.29 rows=1729 width=10)

I wonder if a hash join would be faster. What does EXPLAIN show if
you first do "set enable_mergejoin to off"? What's the actual
performance in both cases?

Also, it's possible that the performance problem isn't the fault of the
plan at all. Are there multiple rows in t_host matching the deletable
rows of t_haus? I'm wondering if there's some speed penalty associated
with trying to delete the same row multiple times in one command...

regards, tom lane