Am 02.02.2012 22:00, schrieb Gordan Bobic: > On 02/02/2012 06:33 PM, Paul J Stevens wrote: >> On 02/02/2012 02:32 PM, Reindl Harald wrote: >> >>> SELECT DISTINCT m.message_idnr FROM dbmail_mimeparts k LEFT JOIN >>> dbmail_partlists l ON k.id=l.part_id LEFT JOIN >>> dbmail_physmessage p ON l.physmessage_id=p.id LEFT JOIN dbmail_header h ON >>> h.physmessage_id=p.id LEFT JOIN >>> dbmail_headervalue v ON h.headervalue_id=v.id LEFT JOIN dbmail_messages m >>> ON m.physmessage_id=p.id WHERE >>> m.mailbox_idnr = 1406 AND m.status IN (0,1) AND v.headervalue LIKE >>> '%charsettest%' OR k.data LIKE BINARY >>> '%charsettest%' ORDER BY m.message_idnr; >> >> Dude, that's a full mailbody search. Horde does that just to login??? I >> can't believe that. And no, this does not sound like a regression in 3.0. >> >> Full body searches will always trigger table scans since mail content is >> *not* indexed. And won't be until we somehow implement full-text search >> - which has all kinds of other issues. > > What's wrong with MySQL's FTS for this functionality?
it does simply not exist currently you cannot use MyISAM for a mailserver InnoDB will support FTS in the upcoming 5.6 release however, i guess the "select distinct" is the problem MySQL is really weak with distinct/order by in my php apps i use normaly array_unique() and sort-functions of php because they are much faster as mysql most of the time and as additional benefit the application will use mysql query cache better
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DBmail mailing list [email protected] http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
