This is nice patch but it is a patch. Plus also it is proof of concept so I’m not sure it is good enough to be used widely in production. Note as long as you start messing with data such a way you’ve got to deal with a lot of niche cases to make things work 100% – for example what happens if you crash during writing dump file ? How to deal with such file potential corruptions (store checkums and validate them) etc. But in general it is nice idea for many workloads.

CREATE TEMPORARY TABLE blackhole_foo ENGINE = BLACKHOLE SELECT * FROM foo ORDER BY id

it does seem a shame that ‘create table like’ doesn’t allow for specifying the engine.

This only works for tables that fit 100% in memory. Some people use the LRU semantics to cache their data.

It’s harder to get this working as you have to ‘warm up’ a box with new load.

One way to this could be to slowly expose it to more and more traffic.

Kevin

innodb_pre_load_tables=List_of_tables

as configuration variable allowing frequently used tables to be loaded (provided it fits)

Along with something like ..

PRELOAD [FULL] TABLE foo

Too many statements I’m also wondering if it is faster or slower than count() query as it has to go through insert code path at least on server side.

There are two other potential issues – it is possible for not innodb tables (or not primary keys) last query to pick to do filesort instead of table scan. Plus if you repeat the thing for bunch of indexes you will have considerable overhead by accessing row each time, not traversing index only.

on bootup just run

CREATE TABLE BLACKHOLE_FOO LIKE FOO;
ALTER TABLE BLACKHOLE_FOO ENGINE = BLACKHOLE;
SELECT * FROM FOO ORDER BY ID INTO BLACKHOLE_FOO;

and repeat for every index.

If your tables all fit into memory you’ll be loaded in seconds.