correlated delete with "in" and "left outer join"

[mike]

I'm using postgresl 7.3.2 and have a query that executes very slowly.

There are 2 tables: Item and LogEvent. ItemID (an int4) is the primary key
of Item, and is also a field in LogEvent. Some ItemIDs in LogEvent do not
correspond to ItemIDs in Item, and periodically we need to purge the
non-matching ItemIDs from LogEvent.

The query is:

delete from LogEvent where EventType != 'i' and ItemID in
(select distinct e.ItemID from LogEvent e left outer join Item i
on e.ItemID = i.ItemID where e.EventType != 'i' and i.ItemID is null);

I understand that using "in" is not very efficient.

Is there some other way to write this query without the "in"?

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddres sHere" to ma*******@postg resql.org)

[Michael Chaney]

> >The original subquery looked like:

select distinct e.ItemID from LogEvent e left outer join Item i
on e.ItemID = i.ItemID where e.EventType != 'i' and i.ItemID is null

Please, before continuing this thread, read my post below. What you're
all getting around to, albeit painfully, is that this subquery is
worthless as-is. This is the mysql way of finding rows in one table
with no match in another without the convenience of the "in" or "exists"
constructs.

Because we're using Postgres and have those constructs, the original
query can be rewritten simply with either:

delete from LogEvent where EventType != 'i' and ItemID not in
(select ItemID from Item)

That's it. That's the whole query. It does what he wants.

Michael
--
Michael Darrin Chaney
md******@michae lchaney.com
http://www.michaelchaney.com/

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

[Mike Mascari]

Michael Chaney wrote:

Please, before continuing this thread, read my post below. What you're
all getting around to, albeit painfully, is that this subquery is
worthless as-is. This is the mysql way of finding rows in one table
with no match in another without the convenience of the "in" or "exists"
constructs.

Because we're using Postgres and have those constructs, the original
query can be rewritten simply with either:

delete from LogEvent where EventType != 'i' and ItemID not in
(select ItemID from Item)

That's it. That's the whole query. It does what he wants.
One more minor point. :-)

If you are using 7.3 or earlier, PostgreSQL will sequentially scan
the IN subquery result, which executes quite slowly and therefore
the EXISTS method Stephan stated should be used:

DELETE FROM LogEvent
WHERE EventType != 'i' AND NOT EXISTS (
SELECT 1
FROM Item
WHERE Item.ItemID = LogEvent.ItemID
);

If you are using >= 7.4, then your query above is optimal:

http://www.postgresql.org/docs/7.4/s...ml#RELEASE-7-4

Just something to consider,

Mike Mascari

Michael

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

[Michael Chaney]

On Fri, Feb 27, 2004 at 12:05:48PM -0500, Mike Mascari wrote:

Michael Chaney wrote:

Please, before continuing this thread, read my post below. What you're
all getting around to, albeit painfully, is that this subquery is
worthless as-is. This is the mysql way of finding rows in one table
with no match in another without the convenience of the "in" or "exists"
constructs.

Because we're using Postgres and have those constructs, the original
query can be rewritten simply with either:

delete from LogEvent where EventType != 'i' and ItemID not in
(select ItemID from Item)

That's it. That's the whole query. It does what he wants.

One more minor point. :-)

If you are using 7.3 or earlier, PostgreSQL will sequentially scan
the IN subquery result, which executes quite slowly and therefore
the EXISTS method Stephan stated should be used:

DELETE FROM LogEvent
WHERE EventType != 'i' AND NOT EXISTS (
SELECT 1
FROM Item
WHERE Item.ItemID = LogEvent.ItemID
);

If you are using >= 7.4, then your query above is optimal:

Not necessarily. I had a query just last week that still wouldn't
optimize with the "in" notation, but did optimize with "exists"
notation. My other post about this showed both queries for that reason,
but I still feel that, for academic purposes, the "in" clause is far
more readable.

Anyway, good point.

Michael
--
Michael Darrin Chaney
md******@michae lchaney.com
http://www.michaelchaney.com/

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[Stephan Szabo]

On Fri, 27 Feb 2004, Mike Mascari wrote:

Stephan Szabo wrote:

On Fri, 27 Feb 2004, Mike Mascari wrote:

To do what I think you believe to be happening w.r.t. outer joins,
you'd have to have a subquery like:

[test@lexus] select a.fookey
test-# FROM
test-# (SELECT foo.key AS fookey, bar.key as barkey FROM foo LEFT
OUTER JOIN bar ON foo.key = bar.key) AS a
test-# WHERE a.barkey IS NULL;
This AFAICS is pretty much what he did, except that he didn't alias the
join which is okay I believe. He had one condition in on and two
conditions in where.

The original subquery looked like:
select distinct e.ItemID from LogEvent e left outer join Item i
on e.ItemID = i.ItemID where e.EventType != 'i' and i.ItemID is null

That is indeed the original subquery. But the 'i.ItemID is null'
condition doesn't change the IN list one iota. He was somehow

.... Another example:

[test@lexus] select * from foo;
key
-----
1
3
(2 rows)

[test@lexus] select * from bar;
key | value
-----+-------
1 | Mike
2 | Joe
(2 rows)

[test@lexus] select foo.key, bar.key from foo left outer join bar on
foo.key = bar.key and bar.key is null;

ON conditions and WHERE conditions are different.

Try
select foo.key, bar.key from foo left outer join bar on foo.key=bar.key
where bar.key is null;

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[Mike Mascari]

Stephan Szabo wrote:

ON conditions and WHERE conditions are different.

Try
select foo.key, bar.key from foo left outer join bar on foo.key=bar.key
where bar.key is null;

Yep. Sorry.

Mike Mascari

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postg resql.org