2016-04-21 8:16 GMT+02:00 Cecil Westerhof <cldwesterhof at gmail.com>:
> > 2016-04-21 7:50 GMT+02:00 Cecil Westerhof <cldwesterhof at gmail.com>: > >> ?I think it is an edge case. On my real system I only got this when there >> where 1E8 records. I am now testing on very old (8 year) hardware to and >> from work. >> The processor is: >> Intel(R) Atom(TM) CPU N270 @ 1.60GHz >> with 1 GB of RAM. I am now generating a database with 1E6 records (will >> take some time) and will check then with the small database. I expect that >> I then will not see this kind of things. That would explain why nobody sees >> something. >> > > ?As I expected: with a tenth of the records, the performance is as > expected: DROP is faster as DELETE and DROP. (Even faster as the DELETE.) > > > But I am afraid that uploading a file from 4 GB could be a challenge. >> > > ?I have an idea how to get this done, but I have to try some things out. > That is a little difficult while traveling. ;-) > ?Well, I did it. And I want to share the results. I think I found a way to get the results reproduced on a ?normal? system.? ?With createBigTable.sh it is possible to create the big table needed to reproduce the problem. In my case multiplication with a factor ten was enough, but when more is needed the script is easily modified. (Just change NR_OF_COPIES to 25 for example.) What I find very interesting is that the user time and the sys time does not increase significantly, but the real time does. Does this point to the problem, or is this to be expected? Then you have to cp checkUUID.sqlite to checkUUID.sqlite.bck and the testing can begin. For this I wrote performanceTest.sh. It does a drop for both tables and a delete with drop for both tables. First with SECURE_DELETE=1 and then with SECURE_DELETE=0 ? This shows that it is not only the size of the table, but also the size of the database that is significant. The table which had no problems before takes now also long. In all cases the DELETE and DROP is significantly faster as the DROP only. The strange thing that the difference is bigger for the small table as the big table. I hope that it is now possible to reproduce the problem on ?normal? systems. When more information is needed: let me know. -- Cecil Westerhof
