I think the biggest performance increase you will get from varchar over text is that varchar can be indexed, so if you switch from text to a suitably large varchar then index the varchar you should get a decent performance increase.
On Feb 27, 5:23 am, Lukasz Szybalski <[email protected]> wrote: > On Feb 26, 1:59 am, Rowan <[email protected]> wrote:> In response to > your points > > > 1. To get the results of the query it has to be run, so no. > > I wish there was a way to pull up a "http://example.com/trac/query? > status=new&status=reopened&order=priority&milestone=MyCategory_Other&contra > ct_number=123" > but wait for user to enter the contract# into the field before query > gets run. > > aka:http://trac.edgewall.org/query?priority=highest&priority=high&status=... > but user wants a different ticket# > > > 2. That's the nature of MySQL each time an update is run on a table > > the query cache is cleared for any queries that are run on that table. > > ok > > > 3. I've not investigated trac's database structure but that is one > > long query, what is the actual aim of the query? > > This is a query that trac is making by default. When you click on > "view tickets" then custom query" , add your custom field in a query > ui, and the sql statement I've email will run. Actually what I found > out is that mysql TEXT field (custom field) cannot be stored in > memory, and by switching it to varchar you can increase the > performance of the query to 0.1 sec. #6986 > I'm just not sure if that is true or not, and whether it can be done > without breaking trac? > > Thanks, > Lucas -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
