Re: Slow MySQL Workbench startup
On Sun, Jan 9, 2011 at 1:54 PM, Yves Goergen nospam.l...@unclassified.de wrote: Why does it take ages for MySQL Workbench to startup? I rarely use MySQL Workbench. But I remember that reducing the maximum number of items in the undo history greatly improves speed, though maybe not startup time. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Efficient Blobbing?
I am dealing with blobs up to - I estimate - about 100 kilo bytes in size. Storage engine: InnoDB Frontend: PHP Some questions: * I've read somewhere that it's not good to update blobs, because it leads to reallocation, thus fragmentation, thus bad performance. Is that true? Any reference on this? * Initially the blobs get constructed by appending data chunks. Each chunk is up to 16 kilo bytes in size. Is it more efficient to use a separate chunk table instead, for example with fields as below? parent_id, position, chunk Then, to get the entire blob, one would do something like: SELECT GROUP_CONCAT(chunk ORDER BY position) FROM chunks WHERE parent_id = 187 The result would be used in a PHP script. * Is there any difference between the types of blobs, aside from the size needed for meta data, which should be negligible. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Efficient Blobbing?
I am dealing with blobs up to - I estimate - about 100 kilo bytes in size. Storage engine: InnoDB Frontend: PHP Some questions: * I've read somewhere that it's not good to update blobs, because it leads to reallocation, thus fragmentation, thus bad performance. Is that true? Any reference on this? * Initially the blobs get constructed by appending data chunks. Each chunk is up to 16 kilo bytes in size. Is it more efficient to use a separate chunk table instead, for example with fields as below? parent_id, position, chunk Then, to get the entire blob, one would do something like: SELECT GROUP_CONCAT(chunk ORDER BY position) FROM chunks WHERE parent_id = 187 The result would be used in a PHP script. * Is there any difference between the types of blobs, aside from the size needed for meta data, which should be negligible. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Efficient Blobbing?
I am dealing with blobs up to - I estimate - about 100 kilo bytes in size. Storage engine: InnoDB Frontend: PHP Some questions: * I've read somewhere that it's not good to update blobs, because it leads to reallocation, thus fragmentation, thus bad performance. Is that true? Any reference on this? * Initially the blobs get constructed by appending data chunks. Each chunk is up to 16 kilo bytes in size. Is it more efficient to use a separate chunk table instead, for example with fields as below? parent_id, position, chunk Then, to get the entire blob, one would do something like: SELECT GROUP_CONCAT(chunk ORDER BY position) FROM chunks WHERE parent_id = 187 The result would be used in a PHP script. * Is there any difference between the types of blobs, aside from the size needed for meta data, which should be negligible. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
