Matthias Mullie

@rec: Building an AST would indeed enable even way more thorough minifying, but that's not something I'll be doing short-term. Partly because there are other very decent minifiers already anyway - this was just meant to be a fast-running PHP-specific implementation we needed for some project that time.

@hobarrera: That is indeed kind of the point. Although it's a bit ironic I'm trying to make this point over a self-built project (but at the time it started, the alternatives were slim - today, this wouldn't make sense anymore)

Looks like the table tags are not accurately being parsed (or at least, for me they're not) - they are displayed as compressed text in a tiny font. You can resort to the original post (http://www.mullie.eu/aggregate-data-large-datasets-rollup-tables/) to better view these parts.

That query would work, but won't scale well.
Imagine both blog & pages subqueries result in several million results. It's up to MySQL to order these several million UNION-ized results (as a temp table, "match" won't be an indexed column) to pick the first 10.

Good call. It's just the the other way around: < 5.6 no FULLTEXT :)
But indeed. 5.5 and under only provide FULLTEXT on MyISAM tables. Since 5.6, it's also supported on InnoDB.

Guess it's a common hurdle for quite some open source software.

Great to hear! Once implemented, I wouldn't mind testing it, if you'd provide a link to it ;)

Looks like the table tags are not accurately being parsed (or at least, for me they're not) - they are displayed as compressed text in a tiny font. You can resort to the original post (http://www.mullie.eu/mysql-as-a-search-engine/) to better view these parts.

Looks like the table tags are not accurately being parsed (or at least, for me they're not) - they are displayed as compressed text in a tiny font. You can resort to the original post (http://www.mullie.eu/regular-expressions-basics/) to better view these parts.