[rt-devel] Re: RT SQL 'lockup' (mysql->99% cpu)

[Iain Price]

> On Tue, Jul 22, 2003 at 01:20:08PM +0100, Iain Price wrote:
>
> > PS: I think the issue is the users dont understand the search criteria
dont
> > reset when you go back to the search page... maybe have two buttons,
> > 'search' and 'refine search'?
>
> It used to be that way. It confused users too much.
>
Just cant win eh :)

 > dunno, i can see this issue in two lights - a)
> > stupid user, who cares, rt does what it does, or b) users can completely
> > halt RT functionality which is a disaster - completely opposing views,
> > Jesse, which approach do you take for RT - user or admin tool?
>
> I train my users.  If your users have a legitimate need for searching
> for tickets with a combination of multiple requestor addresses, it's
> probably worth looking at the queries RT's generating and seeing what
> can be done indexwise to increase the performance.

Heh i dont think its intentional.  Many of the searches are for the same
address repeatedly, otherwise when an initial search fails to find a result
they add another requestors email - which works, its an OR clause and all
that, but while 1 requestor email is semi-instant and 2 is slow, 3 is dead
(3 sepearate queried would work better heh)

We've tried educating the users, and are continuing to do so, i dont expect
to see this 3rd layer of the problem often, but its still there and has
already reared its head.

I need a user proof solution to this problem, and attempting to fix the
users generally doesn't work in my experience.  Also theres no easy way to
tie the search query to the user that performed it - in fact i *HOPE* you
can work it out by reading back through the sql thread that made the fatal
query, reading the last used session id and tracking that back to a session
set and reading the email address from the binary object shoved in the DB -
is there a better way than this?  Will this method work? :P

Iain