On Thu, Feb 12, 2009 at 06:25:59AM -0800, MARK CALLAGHAN wrote:
> For things that cannot be instrumented at the storage engine
> interface, it would help to expose an API that the engine can use. For
> example, patched InnoDB doesn't have much contention on
> pthread_mutex_t. But it has a lot of contention on its mutex
> implementation and it counts that, but there isn't a generic way to
> report that and for now SHOW MUTEX STATUS is the interface to the
> data.
I'd very much like to fix this shortly. I think the FRM to proto work is
a prerequisite.
I aim to have something similar to NDB$INFO, but for the server as a
whole.
basically a simple API to read values as rows.
If the performance schema tree was up somewhere, I'd compare with it...
but it's not, so I'll give an example using NDB$INFO.
For our memory pools, we define the table:
DECLARE_NDBINFO_TABLE(ndbinfo_POOLS,5)
= { "POOLS", 5, 0,
{
{"NODE_ID", NDBINFO_TYPE_NUMBER},
{"BLOCK", NDBINFO_TYPE_STRING},
{"POOL_NAME", NDBINFO_TYPE_STRING},
{"FREE", NDBINFO_TYPE_NUMBER},
{"SIZE", NDBINFO_TYPE_NUMBER},
}
};
and then software modules get called as part of a scan operation to get
their data. For example, from the BACKUP block memory pools:
struct {
const char* poolname;
Uint32 free;
Uint32 size;
} pools[] =
{
{"Backup Record",
c_backupPool.getNoOfFree(),
c_backupPool.getSize() },
{"Backup File",
c_backupFilePool.getNoOfFree(),
c_backupFilePool.getSize() },
{"Table",
c_tablePool.getNoOfFree(),
c_tablePool.getSize() },
{"Trigger",
c_triggerPool.getNoOfFree(),
c_triggerPool.getSize() },
{"Fragment",
c_fragmentPool.getNoOfFree(),
c_fragmentPool.getSize() },
{"Page",
c_pagePool.getNoOfFree(),
c_pagePool.getSize() },
{ NULL, 0, 0}
};
for(int i=0; pools[i].poolname; i++)
{
dbinfo_write_row_init(&r, buf, sizeof(buf));
dbinfo_write_row_column_uint32(&r, getOwnNodeId());
const char *blockname= "BACKUP";
dbinfo_write_row_column(&r, blockname, strlen(blockname));
dbinfo_write_row_column(&r, pools[i].poolname,
strlen(pools[i].poolname));
dbinfo_write_row_column_uint32(&r, pools[i].free);
dbinfo_write_row_column_uint32(&r, pools[i].size);
dbinfo_send_row(signal, r, rl, req.apiTxnId, req.senderRef);
}
The idea being that if you have more than a few rows, there's a
(slightly) more complex API for setting a cursor so that we can context
switch in the meantime (as NDB implements its own).
With the cursor, you can "fake" some indexes to not have to scan
everything (there is a plan to have each active operation record be a
row in a NDB$INFO table.. so this may be useful if you only want a
subset). This is a "version 2" feature though :)
There is no consistency for the whole table (or between rows). very much
READ_UNCOMMITTED and not REPEATABLE_READ.
This seems like it would be easy to use to export the InnoDB mutex stats
as real tables in the database server...
So i'd at least like to have something like NDB$INFO, but not NDB
specific for Drizzle. Do you think this would be a useful addition? Can
probably knock it off in a few days once the FRM work is done...
For those interested in how we generate the FRM for NDB$INFO, the data
dictionary tables for NDB$INFO have a column for "sql" which is a CREATE
TABLE statement that if executed will create a table like the NDB$INFO
one. So the MySQL Server simply scans the NDB$INFO.TABLES table and runs
the SQL to generate a FRM. With Drizzle and the proto, we can just
generate the proto directly.
--
Stewart Smith
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
