R.Smith,
Thank you for the reply.
I'm pasting again the original message that explains which versions I
have tested on which Operating System.
/I have tested this code with version 3.8.10.2 using "DB Browser for
SQLite" and it would crash; the same with SQLite Manager that uses the
same version. I have decided to use the latest SQLite version available
from GNU / Linux Debian testing 64-bit; it's 3.8.11.1 and something
strange is happening. I hope I'm the reason behind its rather peculiar
behavior.//
////
//I tested the following code //
////
////*sqlite> drop table if exists t1; create table t1(a datetime);
begin; with recursive c(x) as (values(1) union all select x + 1 from c
where x < 1000000000) insert into t1(a) select datetime('now') from c;
commit;*//
////
//It would take ages to finish and that is logical; it's a billion rows
it has to insert, even though I have used begin - commit.//
////
//Now the rather strange behavior would be when I use the up arrow key
to reuse the previous code but replacing //*1000000000*//with //*10*//.
It takes the same time to finish as before and that is not right; I'm
dropping the table and it should take nearly 0 milliseconds for 10 rows.//
////
//Can someone confirm this?//
////
//Cheers./
So in other words, what I did was the following:
* I ran the aforementioned command with a billion rows, waited for it
to finish; it took some minutes to complete its task.
* re-run the same command but with 10 rows only; it *should* have
finished within milliseconds, but it repeated the same task as
above, even the database size remained the same (28GB that is).
On 08/28/2015 05:45 PM, R.Smith wrote:
>
>
> On 2015-08-28 03:09 PM, Yahoo! Mail wrote:
>> Where did you see the vacuum happening inside the transaction? It's
>> just right before begin...anyway. It seems I'm unable to make clear
>> the actual "issue" of mine, but anyhow it's not a bit deal. I just
>> wanted to report what I have noticed, that's all.
>
> No no, I did not say you did the vacuum inside a transaction, I meant
> that if I had to include that in my script to see the timed-output
> from it (because I suspected it might take a long time), it would have
> had to be part of the transaction - which of course it cannot be, as
> you already know.
>
> And please do not be dismayed, we would like to assist or at least
> understand your issue because the idea we now have is that you have a
> version of SQLite that somehow takes almost 2 minutes to drop a table
> with only 100-million rows with only dates in it. This would be
> horrible. We are not trying to prove you wrong, we are trying to
> establish the facts.
>
> What we (myself and other responders) tried to show is that SQLite
> does not do that for us at all.. our tables of that size drop in about
> 3 to 6 seconds - which means (the bit we do not specifically say
> because we do not wish to bore everyone with detail) that:
>
> A - We do not get the same results as you, so either there is
> something about your use-case we do not know and you did not state, or
> B - We are not understanding what you mean precisely, so will need a
> bit more description, or
> C - You are using a much different version than we are and you have
> uncovered a bug - in which case we will need to know the specifics:
> - Which version?
> - Did you compile it yourself? Or downloaded from the site?
> D - Your hardware / OS is not playing ball - in which case we will
> need specifics.
>
> In fact, we will need more and more specifics until we can find a case
> that does for us exactly what it does for you, or where we understand
> the difference exactly.
>
> And - if this is a real possibility of a bug, or even just a missed
> opportunity for optimization, we would really like to know it - so
> please try to clarify.
>
> Thanks,
> Ryan
>
>
> PS: We also know your first language isn't English, neither is mine,
> so please bear in mind that we might not clearly understand the first
> time you say something - but that doesn't mean we do not want to
> understand, so don't give up - explain more!
>
> _______________________________________________
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
