[daniel]

peterlaursen wrote on Jun 8 2009, 04:18 PM:

and “Export table data/result as…” is not intended for backup of tables but for exporting result sets (actually if you use it with a table a warning popup will display).

Fair enough….but there are loads of times I draw reports for analysis that produce over 1 million entries. Anyway, if you can get a speed increase, then happy days.

D.

[daniel]

peterlaursen wrote on Jun 8 2009, 01:29 PM:

Please wait for the developer team to comment. Manohar has not been working with SQLyog for more than a year (he is with MONyog now), so this is a little bit strange.

Sorry, in fairness it was put in in Rev: 73 (6.14 RC2) November 2007. I'm not suggesting he is to blame per se. Back in 2007 there may have been a very good reason to do that with the current MySQL Native API, but it doesn't appear necessary now.

Also it looks like you guys just push a snapshot of internal code to the googlecode when a release is done, so it could really just be anyone who put it in originally.

D.

[daniel]

Me again,

Quote:

Is there some particular reason the seek is in there?

Did a SVN Blame….line was put in by [email protected] <_< :P But the SVN entry doesn't list a reason, just the release that it was put in for….. D.

[daniel]

Did some quick testing. Without the explicit seek >600 000 rows took about 90 seconds to export. WITH the explicit seek, it becomes increasingly slow as more rows are export (internally it may be a linked list, which would explain the increasing seek time for a row that is deeper). After about 40 000 rows it was crawling….I'd guess it would take > 1 hour to export all of them.

So the question is; Is there some particular reason the seek is in there? Hopefully there isn't and we can chop that line and get some fantastic speed increases.

D.

[Author]

Posts