[rt-users] RT2 and MySQL

[Matthew Watson]

haha. so I'm not the only person to be bitten by this one.. RT2 is REALLY
slow
at searching for tickets by requestor.. and i've had no luck in indexing
this
query at all...and it just goes into a downward spiral if you let
staff try and search on more than one requestor..


> -----Original Message-----
> From: rt-users-admin at lists.fsck.com
> [mailto:rt-users-admin at lists.fsck.com]On Behalf Of Byron Ellacott
> Sent: Thursday, 23 May 2002 4:25 PM
> To: Joshua Mandelberger
> Cc: rt-users at fsck.com
> Subject: Re: [rt-users] RT2 and MySQL
>
>
> On Thu, 2002-05-23 at 03:36, Joshua Mandelberger wrote:
> > tmp table | SELECT DISTINCT main.* FROM Tickets main, Watchers
> Watchers_1,
> > Watchers Watchers_3  LEFT JOIN Users  |
>
> Adam, this is caused by the Search facility.
>
> Due to the design of the Watchers and Users tables, a join must be done
> across them to select an email address.  One table or the other has an
> apparently unused email address column that would solve the issue, but I
> don't recall which now, and never investigated why it's unused...
>
> But that aside, what you'll find is happening will be a user who is
> searching for two email addresses, most likely because they don't
> understand how the RT Search works and are adding a search by email
> address twice.  This causes DBIx to produce the above ugly query, which
> in turn causes MySQL to lock up tight.  The same problem occurs if you
> attempt to search ticket content, for much the same reason.
>
> I don't know offhand if this is a problem with the queries being
> generated by DBIx, or an insurmountable problem caused by the table
> design, or a problem with the way MySQL is handling the problem; instead
> I hacked around it to prevent users from querying email address or
> content more than once per search.  Attached is a patch to
> .../lib/RT/Interface/Web.pm which will solve your immediate problem.
>
> --
> bje
>