Hello,
I'm a senior student at university of Roma 3; I'm doing a thesis aiming to provide a
better sinergy between Grass and MySQL (using the
fast all in memory engine); I found that heap engine doesn't support Gis Data because of
the absence of Blob support, through which GIS
data are, at the moment, stored. I also found that blob data aren't supported because
memory engine has a fixed row format, which is
incompatible with blobs.
Writing on mysql forums (http://forums.mysql.com/read.php?92,130771,130771#msg-130771)
this idea is growing up:
>Your idea sounds interesting. I added to our internal todo list:
>"
>Add a pointer to the fixed length record for every blob. Store the blob elsewhere.
> While records are stored bottom up in >the tables
memory pool, we could perhaps allocate blobs top down. The table is full when they meet in
the middle. To >reduce fragmentation, we could
store the blobs in chunks of record size. Perhaps even link them in a chain so that
>fragments can be reused. OPTIMIZE could move lower
fragments up into gaps so that more records can be added.
>
>The charm of the idea is that we won't need to implement "real" variable length
> records. This should make things much >simpler.
>"
Ingo has got the point of my idea: the fixed lenght row format would remain, just the blob
column size would be the lenght of memory
address in which a pointer to elsewhere in memory may be memorized to retreive real data
of the blob.
I'm working with 5.1.15-beta source code. It seems to me that the obvious way to start is
to add hp_blobs.c (hp_blobs.h) to the "mysql-
5.1.15-beta/storage/heap", but it could not be so. Which other files and parts of the code
would be interested in this modification and
should be analyzed/modified?
I hope to read from you all soon. Thanks.
Manu
Naviga e telefona senza limiti con Tiscali
Scopri le promozioni Tiscali adsl: navighi e telefoni senza canone Telecom
http://abbonati.tiscali.it/adsl/
