I had written:

>> That is no surprise. But it is "the additional OR" that does the damage, it is all that NOT logic in the WHERE clause.

It should read: ..But it is NOTE "the additional OR" that does the damage.."

At 12:50 AM 24/04/2008, Tim Gahnström wrote:

>I will also look into your suggestion to remove the FIRST 1 altogether, I didn't know it was expensive (why is it, I don't have a sort or anything I just want 1).

**Inside a SP**, if you just want one row and you don't care which one, then it doesn't make sense to use a noisy construct that's designed to find a specific row.

>I will also sweep through the whole database for similar situations and also look for ways to remove Ors the way Maxim suggested.

ORs per se are not bad, if an index can be used for the search. AND NOTs are no better than OR NOTs. NOTs are bad, because they deny the use of an index for the search. Rather than stripping out ORs you should concentrate on reviewing logic to avoid NOT searches as much as possible. That goes for DSQL just as much as for your PSQL code.

The approach I offered "works like a charm" because it's a textbook example of how PSQL logic gives you a "win" by letting you deal with the NOT logic in PSQL tests before you throw the query at the database. We grab one set by the fastest route - an indexed search - and go home.

./helen