tedd wrote:
Jochem said:
reorder the fields so that the VARCHARS are at the end of the
table (and the BLOB field at the very, very end of the table).
Why the importance of BLOB's being at the end of the table?
its a guestimate based on something I read a while back, the
reason was something silly and not inherent to the blob but some
implementation technicality - the proposed 'solution' was to
move the blob id to the end. it had nothing to do with blob size.
Isn't assigned memory just blocks of reserved addresses for the
requesters use? It shouldn't make any difference where, or how much, a
block of memory is. To move from a field in a record to another field is
just following memory addresses from one field to another field in each
record. It doesn't make any difference if the jump is 1 byte of a
million bytes, it's just an address.
right but fixed sized jumps are best (base 2 anyone?) - i.e. no varchars.
also experiment with table types in mysql - maybe use a 'temporary' HEAP
or MEMORY table to process and then select back into the 'permanent'
table when your done with the heavy lifting.
An address, btw, which can be moved by a memory manager or other such
memory shuffles via handles (pointer to pointers) to provide larger
contiguous blocks of available memory. So, as such, your table may
contain fields where the individual records have blocks of assigned
memory scattered throughout memory with no order other than links to
addresses. It's a binary tree of some sort with blocks of memory hanging
off a linked list like leaves on a tree. The trunk of the tree doesn't
care how large the leaves are.
And deleting blocks of memory is nothing more than severing a link by
swapping memory addresses to connect with what came before to what comes
after. So, trying to place large blocks of memory at the end of the
table is not really doing anything because in assigning memory, there is
no distinction of where you get memory or how much you need -- you
either get the memory you need or fail -- to quote Yoda -- "Do, or not
do. There is no try."
Or is there something here that I don't understand about this type of
memory?
I'm _guessing_ yes.
how about easy to calculate (i.e. + N) memblock positions in physical
memory?
I'm just thinking out loud - don't consider me an authority.
tedd
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
