2016-04-20 12:35 GMT+02:00 R Smith <rsmith at rsweb.co.za>: > > > On 2016/04/20 10:50 AM, Cecil Westerhof wrote: > >> 2016-04-20 10:44 GMT+02:00 Dominique Devienne <ddevienne at gmail.com>: >> >> On Wed, Apr 20, 2016 at 10:36 AM, Cecil Westerhof <cldwesterhof at gmail.com >>> > >>> wrote: >>> >>> I am baffled. Still DELETE before DROP is a lot more efficient. And it >>>> looks that it is not bothered when other programs are running (most of >>>> the time). I would think that a DROP should take the least time: >>>> >>>> I agree. That's weird. Needs investigating indeed. >>> >>> ?Do the developers reed this list, or should I post a bug report? >> > > The Devs do read the list, and often post, and they will be very > interested in what you have discovered if it is not a system anomaly on > your side. (Perhaps even if it is). Can you post the DB file somewhere and > the steps to reproduce? >
?It is 512 MB, thus that is a bit difficult. But would a Java program to generate it suffice? The steps to reproduce is to run the script I posted. That supposes you run Linux, but it should be easy to adapt. > Also, there is no need to file a bug report for this since it is not a > bug. A bug is typically considered to be a bug if the answer produced from > a query is wrong. Since everything happens as expected, you are dealing > with an efficiency regression at best - still of interest, but not a bug. > (The distinction matters because bugs gets the highest priority for > attention, and sometimes cause unscheduled releases to fix - something an > optimization would never cause). > ?Well, I would expect a DROP to be more efficient as a DELETE and DROP. ;-) But I agree that wrong results aremuch more important. -- Cecil Westerhof
