Drupal performance

It might be better to break each patch to its own issue and write up a description for each.

Some interesting changes, but those SQL changes are not ideal at all. The block.patch removes a db_rewrite_sql which removes access checks and could display unwanted data. In the taxonomy.patch, I'm not sure how performing a subquery and an extra inner join is an improvement. In the file.patch, please use a static variable and not a global variable, that's not going to improve performance by introducing a new global. The pathauto patch should be filed against the path auto module, and not against core.

re block.patch - db_rewrite_sql() exists for a reason

First, thanks for sharing this info with the Drupal community. We need to see more companies share their experiences this way.

Second, for Drupal core, try to check Drupal 7.x, and create the patches against that version. Patches are rarely applied to stable versions (5.x, and 6.x), so your chance of getting those in are much better for Drupal 7.x.

Third, split those patches in several issues, as someone said above. Note that for pathauto, you can still specify 5.x and see what the maintainer thinks. I have run into this issue when tracing things, and it is a good patch to avoid file system access several times.

One patch has references to non existing fields (page_crc32) too.

Keep in mind that this website, drupal.org, has almost 350,000 nodes running the current Drupal 5.12, and in 2006 was serving 8 million page views per month. I don't think the code changes to core you've made will really make a much of a difference compared to a proper PHP/MySQL configuration and optimization, like have stated you have made. We also have several awesome performance gurus (Jeremy, David and chx) that are actively involved in improving Drupal's queries and performance bottlenecks.

For further patches, please take a look at the Drupal core coding standards. For further performance patches, please also included some apache ab benchmarks for before/after comparison, and file each patch separately.

These optimizations are not be polished enough for direct inclusion in core, but the strategies described in the PDF are legitimate. I'd prefer to not do a "SELECT * ... ORDER BY" on tables with TEXT columns and instead adopt a load-on-demand scheme for the TEXT fields.

That said, these need to be posted as fresh issues. I'll start by posting one about sorting tables where the queries use TEXT columns.