EyeQL currently has many flaws in its implementation leading to poor response times, particularly with the JIRA FishEye plugin

• Searches are either done only against Infdb and sometimes are a join between infdb and lucene
• Sorts are done in memory
• Lucene queries are done against a changeset index, then split into file revisions, only to be aggregated again
• Many queries could be serviced purely by lucene due to stored data
• file revisions are eagerly loaded for every matching file revision, regardless of whether all fields are required of not

Short term solution
Create a separate API to service the JIRA FishEye Plugins needs, optimising the searches as best they can.

Long term solution
Fix EyeQL to:

• Allow searching for changesets, not just file revision
• Do a lucene first query, lazily fetching file revisions or changeset data from infdb
• use lucene for sorting results where possible