<div dir="ltr">to be clear, on my typo there in the 3rd frm last line;<div><br></div><div>I could NOT be happier with how that went. </div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Jun 2, 2018 at 9:43 PM Drew Jensen <<a href="mailto:drewjensen.inbox@gmail.com">drewjensen.inbox@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Howdy <span>Tamás, list;</span></div><div><span><br></span></div><div>Last weekend during the 6.1 bug hunting session I prattled on, over on the QA irc channel, about running the base migration assistant against an odb file holding ~318 thousand records in an embedded hsql database.  </div><div><br></div><div>Thought I'd post a recap here, with an added bit from today.</div><div><br></div><div>Before running the migration assistant;</div><div>Ran SHUTDOWN COMPACT against the original hsql odb which then had a 32.8 Meg disc image. </div><div><br></div><div>- pass one started</div><div>At the 4 hr and 30 minute mark I stopped the soffice process because I had an idea.</div><div><br></div><div>Did the following;</div><div>Dropped all indexes on all tables, recalling this schema is a reporting dataset generated from a larger transaction set so lots of indexing on a smaller number of tables.</div><div><br></div><div>With all indexes gone and cleaned up the disc image was down to 18.5 Megs.</div><div><br></div><div>Started</div><div>- pass two </div><div>Can't say exactly how long it took, as it was late and after seeing this change; during the first run the soffice process was writing data to disc at a steady ~500K Bi/s, </div><div>during the second, without the indexs, the throuput went to ~1.2M Bi/s;</div><div>I went to bed.</div><div><br></div><div>In the morning and the migration complete the disc image was now 24.8 Megs</div><div><br></div><div>Picked that migrated file up again today adding back all, exact, indexing and then jettisoned the old hsql files from the ODB.</div><div><br></div><div>Final disc image, 6.4 Megs. </div><div><br></div><div>BTW, the schema was advantageous in that it holds predominantly numeric data, all character data in varchar or char fields, no blob data at all. It included two text table definitions, which it dealt with properly by ignoring them. And a view which, unfortunately, referenced one of those - but the error again didn't stop the data load. </div><div><br></div><div>Could be happier with the results here.</div><div><br></div><div>My take away, how did I forget to check the indexing? (i'm getting forgetful in my golden years..;)</div><div><br></div><div>Best wishes,</div></div>
</blockquote></div>