RE: IDS 9.20

I'm not sure about 9.20, but I've seen this on 7.x. It always comes back to an 'or' in the where clause. We've had the engine basically seem to stop processing all requests but the one in question for as long as the query takes to execute (or as long as it takes me to kill it). The box is not out of resources at all. The engine is processing just a few dozen calls (or so onperf tells me) and all other threads just sit idle. Immediately after I kill the query, the box comes back to life. By the time I track it down, there is always an 'or' clause in the where statement that seems to confuse the optimizer. If I re-write it without the 'or' or rewrite it with some more parenthesis, the problem usually clears up. Doubt this will help, but it's worth a look. -----Original Message----- From: Neil Truby [mailto:ntruby@netcomuk.co.uk] Sent: Sunday, August 13, 2000 7:34 PM Posted To: informix Conversation: IDS 9.20 Subject: IDS 9.20 IDS 9.20 HC-2 on HP-UX 11.0. I posted a query a few days ago about performance degradation, but answered it myself when I discovered a runaway select/update process caused the issues. But having thought about it, and reproduced the issue with a sequential scan/delete construct, I'm still not happy. I find it hard to believe that a single query, however heavy duty, could freeze out other users to the extent it did. When it was running it could take 20 seconds to build the table list for a dbaccess->query-> info request - it was that bad. And we're talking about an HP N4000 here - a seriously meaty machine. Could it be an IDS 9.20 thing, that a single query could have such an impact? I can't remember it on7.x. Anyway, I'm going to do some comparative testing. But, if anyone does know of any issues in this area, I'd love to know. If youhave any dazzling insight could you copy it to neil.truby@londis.co.uk, as I don't get to the newsgroup too frequently. thanks Neil