Hi Jay,
On Nov 2, 2009, at 3:37 PM, Jay Pipes wrote:
Brian Aker wrote:
Hi!
On Oct 31, 2009, at 11:59 AM, John David Duncan wrote:
but also have a format on-disk that's (a) very space-efficient and
I was thinking about this yesterday, the format of on-disk only
applies to MyISAM. I don't think many people realize how few
primitive types Innodb has (which is fine... I'm not entirely
convinced this makes much of a difference in the 80/20 rule).
InnoDB is not the only engine other than MyISAM, of course :) Paul,
would this apply to PBXT? Toru, could you comment on BlitzDb?
PBXT, like all other engines needs to know the following about each
table field/type:
1) The offset in the MySQL row buffer
2) The length of the value
3) How to compare the value to other values of the same type (required
to support indexing operations).
Then we need to distinguish between 2 things:
A) Internal engine record format: all engines that supports variable
length records, have this. MyISAM, for example, pack and unpacks
variable length records. This process concerns only (1) and (2) above.
In other words, to pack and unpack, we only need to know where the
data is, and what size.
B) Internal data types: This concerns (3) above. Some engines not only
use an internal storage format, they also use internal comparison
routines. MyISAM and PBXT do not do this.
PBXT and MyISAM both use the routines supplied by the MySQL server
front-end to compare data. This actually only translates into a call
back into MySQL in the case of string comparison. All other code (to
compare integers, binary strings, decimal values, etc) is duplicated
in the engine.
This works, and would also work for a GMP based data type: I would
hunt around for the correct calls in MySQL and add them to my field
comparison switch statement. But it is quite a hack, of course.
So to avoid the hack, and make it possible for an engine to support
just about any new type, I would recommend the following:
Add functions to the Field class that can be used directly by engines
to do comparisons.
Cool changes to Field class would include:
a) Given a pointer to the start of a MySQL row buffer, return a
pointer to the field data, and the length of the data.
b) Given a pointer to the data and length of 2 values, compare and
return -1, 0 or 1.
Doing these (simple!) operations with MySQL today requires quite a bit
of hacking.
From a replication perspective, the on-disk format makes no
difference.
If we adjust a few things we could probably just read data types
that were generated by MySQL, aka... translate in the handler, that
we don't currently support. For us it would just be putting a
priority on the static field array in field.cc (which is really the
biggest issue when it comes to having loadable types right now).
Not a hard problem, just one that will take a bit of time to code.
Brian, could you expand/elaborate on what you mean by "putting a
priority on the static field array in field.cc"? Is this something
a non-Brian-person could pick up? The more details you give, the
easier it is for folks to participate in the conversation...
Cheers!
jay
--
Paul McCullagh
PrimeBase Technologies
www.primebase.org
www.blobstreaming.org
pbxt.blogspot.com
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
