Shawn,
I've just found out that most of my emails during this discussion were
NOT posted to the list because I was sending mail in HTML format and
Yahoo was not delivering the bounce notices to me. That explains why you
believed I was not listening to Peter's input - only _his_ messages were
You are correct, that the situation you describe was not clearly presented
in your previous reply. I humbly apologize for any offense.
Using the EXPLAIN you posted in your latest reply, you can translate your
subquery into the following JOINed query
SELECT p.offer_id
FROM paytable p
LEFT JOIN
[EMAIL PROTECTED] wrote:
Devananda,
I have to support Peter on this one. What he submitted to you is a
perfectly appropriate solution. It seems as though you rejected his
assistance before even trying to see if it would work.
On the contrary, I have tried his suggestions and they do not work
Devananda,
I have to support Peter on this one. What he submitted to you is a
perfectly appropriate solution. It seems as though you rejected his
assistance before even trying to see if it would work. There have been and
continue to be SQL-driven databases around that have not had and do not
Devananda,
>Definitely not. The first LEFT JOIN, with the clauses
>"ON
pt.login_id=pab1.login_id ... WHERE pab1.login_id IS NULL",
> does not
make sense.
?!? It's a standard JOIN replacement for NOT IN (...).
>There is not a 1to1 relationship,
These joins neither find nor assume 1:1 rela
Devananda,
OK, get the diescription in ordinary language right, and the query
ought to write itself. Your schema is like this? ...
and you want the paytable rows
(i) for which there is an offers row matching paytable.offer_id, and
(ii) for which there is no pab row where
pab.login_
Devananda,
>Could anyone give me some insight as to which of the following
queries
>is "better" (and why) - or if there is another query that would be
faster than either?
It's late on Friday so I could be missing something, but wouldn't the
following be simpler?
SELECT offer_id
FROM paytab
In general, I try to stay away from very large IN(..) lists because I
have seen them regularly degrade performance, but in this case the
alternative that I have found doesn't seem to perform any faster. Could
anyone give me some insight as to which of the following queries is
"better" (and why)
