Re: [sqlite] Is it possible to connect to an in-memory sqlite

ntag, 14. November 2016 20:39 An: sqlite-users@mailinglists.sqlite.org Betreff: Re: [sqlite] Is it possible to connect to an in-memory sqlite I am very interested in the answer to this question. Currently it seems like the only way to get multiple connection to the in-memory db is with 'cache=

Re: [sqlite] Is it possible to connect to an in-memory sqlite

On 11/14/16, Daniel Meyer wrote: > > Is the right approach to write a custom VFS? > https://www.sqlite.org/src/artifact/e5225bc22e79dde6 -- D. Richard Hipp d...@sqlite.org ___ sqlite-users mailing list

Re: [sqlite] Is it possible to connect to an in-memory sqlite

On 14 Nov 2016, at 7:38pm, Daniel Meyer wrote: > I am very interested in the answer to this question. Currently it seems > like the only way to get multiple connection to the in-memory db is with > 'cache=shared' and I understand that subsequent connections opened to that >

Re: [sqlite] Is it possible to connect to an in-memory sqlite

SQLite INSERT command (Simon Slavin) >8. add "LINE" to famous sqlite user list (Dan Jacobson) > > > -- > > Message: 1 > Date: Fri, 11 Nov 2016 13:28:10 +0100 > From: Bhargava Srinarasi <bhargavab...@gmail.com> > To: sqlite-users@ma

Re: [sqlite] Is it possible to connect to an in-memory sqlite db in Read-Only mode?

On 11 Nov 2016, at 12:28pm, Bhargava Srinarasi wrote: > I know that I can open multiple connections to an In-Memory sqlite database > using file:DB_NAME?mode=memory=shared in sqlite3_open_v2(). > > I open 2 connections to an In-Memory database. One with the flags >

[sqlite] Is it possible to connect to an in-memory sqlite db in Read-Only mode?

I know that I can open multiple connections to an In-Memory sqlite database using file:DB_NAME?mode=memory=shared in sqlite3_open_v2(). I open 2 connections to an In-Memory database. One with the flags SQLITE_OPEN_URI | SQLITE_OPEN_CREATE | SQLITE_OPEN_READWRITE and another with

Re: [sqlite] Is it possible to support 64-bit value in rtree module?

e.org> 主题: [sqlite] Is it possible to support 64-bit value in rtree module? Hi All As we know, the current rtree module supports 32-bit signed value only, Is it possible to support 64-bit? Thanks. Regards gelin yan ___ sqlite-users mailing

Re: [sqlite] Is it possible to support 64-bit value in rtree module?

On 10/10/16, Gelin Yan wrote: > Hi All > > As we know, the current rtree module supports 32-bit signed value > only, Is it > > possible to support 64-bit? Thanks. > This could be done, in theory. But it is of dubious utility, and not something the developers are

[sqlite] Is it possible to support 64-bit value in rtree module?

Hi All As we know, the current rtree module supports 32-bit signed value only, Is it possible to support 64-bit? Thanks. Regards gelin yan ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org

[sqlite] Is it possible that dropping a big table takes very long

23 apr 2016, E.Pasma: > Hello, > I tried the scripts but.. > > createBigTable.sh is beyond the capacity of my system. Instead I > used SQL script like in > www.mail-archive.com/sqlite-users%40mailinglists.sqlite.org/msg08044.html > > My point is that the definition of the table is a waste of

[sqlite] Is it possible that dropping a big table takes very long

Hello, I tried the scripts but.. createBigTable.sh is beyond the capacity of my system. Instead I used SQL script like in www.mail-archive.com/sqlite-users%40mailinglists.sqlite.org/msg08044.html My point is that the definition of the table is a waste of capacity, even though it serves on

[sqlite] Is it possible that dropping a big table takes very long

On 22 April 2016 at 21:24, Adam Devita wrote: > > That said, why is the dropping of a table dependent on the size of > the table? Does Sqlite have to mark every block of memory it used as > dropped? (This is obvious for high security mode, but otherwise?) In rollback journal mode, every

[sqlite] Is it possible that dropping a big table takes very long

On 22 April 2016 at 16:00, Cecil Westerhof wrote: > 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? > It suggests the extra time is spent waiting for I/O

[sqlite] Is it possible that dropping a big table takes very long

2016-04-22 14:06 GMT+02:00 E.Pasma : > > 22 apr 2016, Cecil Westerhof: > >> >> ?With createBigTable.sh ... >> > Can you paste the svript in the message? Attachments are not sent. > ?createBigTable.sh: #/usr/bin/env bash # An error should terminate the script # An unset variable is also an error

[sqlite] Is it possible that dropping a big table takes very long

22 apr 2016, Cecil Westerhof: > > ?With createBigTable.sh ... Can you paste the svript in the message? Attachments are not sent. Regards, E.Pasma

[sqlite] Is it possible that dropping a big table takes very long

On 4/22/16, Rowan Worth wrote: > > I've written this under the presumption that sqlite touches every database > page that was associated with a table during the delete/drop... I can think > of some optimisations allowing much of the i/o to be skipped (at least > least when secure_delete isn't

[sqlite] Is it possible that dropping a big table takes very long

2016-04-22 10:12 GMT+02:00 Rowan Worth : > On 22 April 2016 at 16:00, Cecil Westerhof wrote: > > > 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? > >

[sqlite] Is it possible that dropping a big table takes very long

2016-04-21 8:16 GMT+02:00 Cecil Westerhof : > > 2016-04-21 7:50 GMT+02:00 Cecil Westerhof : > >> ?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)

[sqlite] Is it possible that dropping a big table takes very long

In general, CPUs got much faster than disk IO a long time ago, so it is expected that a single thread, write through to disk program would have lots of time where the is CPU waiting for disk IO to complete. (BTW: A common error of novice db programmers is using a disk based db to store variables

[sqlite] Is it possible that dropping a big table takes very long

21 apr 2016, Cecil Westerhof: > > ?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. Hello, the answer to Cecils question is YES here. I tested on a computer with just 512 Mb

[sqlite] Is it possible that dropping a big table takes very long

2016-04-21 7:50 GMT+02:00 Cecil Westerhof : > ?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

[sqlite] Is it possible that dropping a big table takes very long

2016-04-21 1:37 GMT+02:00 J Decker : > If you upload a file to google drive and later try to replace it with > a different version google drive often corrupts it. Always delete and > upload a new version. > ?That was not the problem. When I unzipped the file I uploaded, it was different as the

[sqlite] Is it possible that dropping a big table takes very long

2016-04-21 1:04 GMT+02:00 jungle Boogie : > On 20 April 2016 at 14:55, Cecil Westerhof wrote: > > This one I download, unpacked and tried. It worked. So it should be > > correct now: > > https://drive.google.com/file/d/0BzW5q7uL-6z0UjFhRWZWSENnZW8/ > > > Windows 8.1 4 gigs of RAM, dell

[sqlite] Is it possible that dropping a big table takes very long

2016-04-20 22:35 GMT+02:00 Cecil Westerhof : > 2016-04-20 22:21 GMT+02:00 Scott Robison : > >> On Wed, Apr 20, 2016 at 2:00 PM, Cecil Westerhof >> wrote: >> >> > How stupid that I did not think about Google Drive. :'-( Here it is: >> >

[sqlite] Is it possible that dropping a big table takes very long

2016-04-20 22:21 GMT+02:00 Scott Robison : > On Wed, Apr 20, 2016 at 2:00 PM, Cecil Westerhof > wrote: > > > How stupid that I did not think about Google Drive. :'-( Here it is: > > https://drive.google.com/file/d/0BzW5q7uL-6z0SDdya2REaFNFUVE > > > > ?I am very curious. > > > > I downloaded

[sqlite] Is it possible that dropping a big table takes very long

2016-04-20 18:11 GMT+02:00 R Smith : > > > On 2016/04/20 5:56 PM, Cecil Westerhof wrote: > >> 2016-04-20 16:07 GMT+02:00 R Smith : >> >> >>> On 2016/04/20 3:31 PM, Cecil Westerhof wrote: >>> >>> ?It is still 411 MB. When I am home I will try it on another system also >>> to >>> look if there the

[sqlite] Is it possible that dropping a big table takes very long

of > Sent: Wednesday, 20 April, 2016 17:55 > To: SQLite mailing list > Subject: Re: [sqlite] Is it possible that dropping a big table takes very > long > > 2016-04-20 22:40 GMT+02:00 Cecil Westerhof : > > > 2016-04-20 22:35 GMT+02:00 Cecil Westerhof : > > >

[sqlite] Is it possible that dropping a big table takes very long

On 2016/04/20 5:56 PM, Cecil Westerhof wrote: > 2016-04-20 16:07 GMT+02:00 R Smith : > >> >> On 2016/04/20 3:31 PM, Cecil Westerhof wrote: >> >> ?It is still 411 MB. When I am home I will try it on another system also to >> look if there the timing is differently. Is there an upload site you >>

[sqlite] Is it possible that dropping a big table takes very long

2016-04-20 16:07 GMT+02:00 R Smith : > > > On 2016/04/20 3:31 PM, Cecil Westerhof wrote: > >> 2016-04-20 12:35 GMT+02:00 R Smith : >> >> >>> On 2016/04/20 10:50 AM, Cecil Westerhof wrote: >>> >>> The Devs do read the list, and often post, and they will be very >>> interested in what you have

[sqlite] Is it possible that dropping a big table takes very long

If you upload a file to google drive and later try to replace it with a different version google drive often corrupts it. Always delete and upload a new version. On Wed, Apr 20, 2016 at 4:04 PM, jungle Boogie wrote: > On 20 April 2016 at 14:55, Cecil Westerhof wrote: >> This one I download,

[sqlite] Is it possible that dropping a big table takes very long

On Wed, Apr 20, 2016 at 3:31 PM, Cecil Westerhof wrote: > >>> ?Do the developers read this list, or should I post a bug report? > They do, and it's actually the preferred way to discuss issues/bugs/performances, etc... Dr. Hipp even wrote not long ago "bugs" entered would be aggressively

[sqlite] Is it possible that dropping a big table takes very long

On Wed, Apr 20, 2016 at 3:55 PM, Cecil Westerhof wrote: > > ?This one I download, unpacked and tried. It worked. So it should be > correct now: > https://drive.google.com/file/d/0BzW5q7uL-6z0UjFhRWZWSENnZW8/ > > ?Made with zip. > Windows 10 1511 with Feb 2016 updates, x64 i7-6700K 4.00GHz

[sqlite] Is it possible that dropping a big table takes very long

On 2016/04/20 3:31 PM, Cecil Westerhof wrote: > 2016-04-20 12:35 GMT+02:00 R Smith : > >> >> On 2016/04/20 10:50 AM, Cecil Westerhof wrote: >> >> 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

[sqlite] Is it possible that dropping a big table takes very long

On 20 April 2016 at 14:55, Cecil Westerhof wrote: > This one I download, unpacked and tried. It worked. So it should be > correct now: > https://drive.google.com/file/d/0BzW5q7uL-6z0UjFhRWZWSENnZW8/ Windows 8.1 4 gigs of RAM, dell latitude with i5 process from a few years ago, lots of tabs

[sqlite] Is it possible that dropping a big table takes very long

2016-04-20 12:35 GMT+02:00 R Smith : > > > On 2016/04/20 10:50 AM, Cecil Westerhof wrote: > >> 2016-04-20 10:44 GMT+02:00 Dominique Devienne : >> >> On Wed, Apr 20, 2016 at 10:36 AM, Cecil Westerhof >> > >>> wrote: >>> >>> I am baffled. Still DELETE before DROP is a lot more efficient. And it

[sqlite] Is it possible that dropping a big table takes very long

On Wed, Apr 20, 2016 at 2:00 PM, Cecil Westerhof wrote: > How stupid that I did not think about Google Drive. :'-( Here it is: > https://drive.google.com/file/d/0BzW5q7uL-6z0SDdya2REaFNFUVE > > ?I am very curious. > I downloaded this and opened it with sqlite3.exe shell version 3.11.0.

[sqlite] Is it possible that dropping a big table takes very long

On 2016/04/20 10:50 AM, Cecil Westerhof wrote: > 2016-04-20 10:44 GMT+02:00 Dominique Devienne : > >> On Wed, Apr 20, 2016 at 10:36 AM, Cecil Westerhof >> wrote: >> >>> I am baffled. Still DELETE before DROP is a lot more efficient. And it >>> looks that it is not bothered when other programs

[sqlite] Is it possible that dropping a big table takes very long

2016-04-20 10:44 GMT+02:00 Dominique Devienne : > On Wed, Apr 20, 2016 at 10:36 AM, Cecil Westerhof > 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

[sqlite] Is it possible that dropping a big table takes very long

On Wed, Apr 20, 2016 at 10:36 AM, Cecil Westerhof 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.

[sqlite] Is it possible that dropping a big table takes very long

2016-04-19 15:27 GMT+02:00 Olivier Mascia : > > Le 19 avr. 2016 ? 14:49, Cecil Westerhof a > ?crit : > > > > SECURE_DELETE > > Are you aware of the net effect of SQLITE_SECURE_DELETE? > > https://www.sqlite.org/compile.html#secure_delete > > The documentation talks about a "small performance

[sqlite] Is it possible that dropping a big table takes very long

2016-04-19 15:29 GMT+02:00 R Smith : > > > On 2016/04/19 2:49 PM, Cecil Westerhof wrote: > >> 2016-04-18 12:47 GMT+02:00 Olivier Mascia : >> >> PRAGMA compile_options; (has SQLITE_SECURE_DELETE been set for compiling >>> the library?) >>> >>> ?sqlite3 checkUUID.sqlite >> SQLite version 3.8.7.1

[sqlite] Is it possible that dropping a big table takes very long

2016-04-19 15:27 GMT+02:00 Olivier Mascia : > > Le 19 avr. 2016 ? 14:49, Cecil Westerhof a > ?crit : > > > > SECURE_DELETE > > Are you aware of the net effect of SQLITE_SECURE_DELETE? > > https://www.sqlite.org/compile.html#secure_delete > > The documentation talks about a "small performance

[sqlite] Is it possible that dropping a big table takes very long

2016-04-19 15:12 GMT+02:00 Simon Slavin : > > On 19 Apr 2016, at 1:49pm, Cecil Westerhof wrote: > > > ?Is it not strange that first DELETE and then DROP is so more efficient > as > > just a DROP? > > Yes. > > Can you please try the same comparison in the SQLite shell tool ? You can > use > >

[sqlite] Is it possible that dropping a big table takes very long

On 2016/04/19 2:49 PM, Cecil Westerhof wrote: > 2016-04-18 12:47 GMT+02:00 Olivier Mascia : > >> PRAGMA compile_options; (has SQLITE_SECURE_DELETE been set for compiling >> the library?) >> > ?sqlite3 checkUUID.sqlite > SQLite version 3.8.7.1 2014-10-29 13:59:56 > Enter ".help" for usage hints.

[sqlite] Is it possible that dropping a big table takes very long

> Le 19 avr. 2016 ? 14:49, Cecil Westerhof a ?crit : > > SECURE_DELETE Are you aware of the net effect of SQLITE_SECURE_DELETE? https://www.sqlite.org/compile.html#secure_delete The documentation talks about a "small performance penalty", yet on very large tables, especially if overflowing

[sqlite] Is it possible that dropping a big table takes very long

2016-04-19 4:43 GMT+02:00 Rowan Worth : > On 19 April 2016 at 02:01, Cecil Westerhof wrote: > > > 2016-04-18 4:04 GMT+02:00 Rowan Worth : > > > > > On 18 April 2016 at 06:55, Cecil Westerhof > > wrote: > > > > > > > ?I put a strace on it. This was what I got: > > > > Process 26455 attached with

[sqlite] Is it possible that dropping a big table takes very long

2016-04-18 12:47 GMT+02:00 Olivier Mascia : > PRAGMA compile_options; (has SQLITE_SECURE_DELETE been set for compiling > the library?) > ?sqlite3 checkUUID.sqlite SQLite version 3.8.7.1 2014-10-29 13:59:56 Enter ".help" for usage hints. sqlite> PRAGMA compile_options; ENABLE_COLUMN_METADATA

[sqlite] Is it possible that dropping a big table takes very long

On 19 Apr 2016, at 1:49pm, Cecil Westerhof wrote: > ?Is it not strange that first DELETE and then DROP is so more efficient as > just a DROP? Yes. Can you please try the same comparison in the SQLite shell tool ? You can use .timer ON DELETE FROM myTable; DROP TABLE myTable; .timer OFF

[sqlite] Is it possible that dropping a big table takes very long

On 19 April 2016 at 02:01, Cecil Westerhof wrote: > 2016-04-18 4:04 GMT+02:00 Rowan Worth : > > > On 18 April 2016 at 06:55, Cecil Westerhof > wrote: > > > > > ?I put a strace on it. This was what I got: > > > Process 26455 attached with 20 threads > > > % time seconds usecs/call calls

[sqlite] Is it possible that dropping a big table takes very long

was dropped in about 13 > seconds. > I will try it again with 1E8 elements, but it takes 4? hours to generated. > Is it possible that SQLite has trouble dropping very large tables? It was > 5.2 GB. With 1E7 elements the table is 512 MB. > > The definition of the table: > CREATE T

[sqlite] Is it possible that dropping a big table takes very long

t with a table of 1E7 elements. That was dropped in about 13 >> seconds. >> I will try it again with 1E8 elements, but it takes 4? hours to generated. >> Is it possible that SQLite has trouble dropping very large tables? It was >> 5.2 GB. With 1E7 elements the table is 512 MB. >> &g

[sqlite] Is it possible that dropping a big table takes very long

On 18 April 2016 at 06:55, Cecil Westerhof wrote: > ?I put a strace on it. This was what I got: > Process 26455 attached with 20 threads > % time seconds usecs/call callserrors syscall > -- --- --- - - > 99.80 11245.498406

[sqlite] Is it possible that dropping a big table takes very long

2016-04-17 18:23 GMT+02:00 Simon Slavin : > > On 17 Apr 2016, at 5:13pm, Cecil Westerhof wrote: > > > Or is this normal > > in Java programs? > > Yes. You're discovering that Java is rubbish. 'futex' for Java is what > most environments call 'mutex' and Java doesn't do locking well. It's this

[sqlite] Is it possible that dropping a big table takes very long

2016-04-17 21:59 GMT+02:00 Scott Robison : > On Sun, Apr 17, 2016 at 1:44 PM, Cecil Westerhof > wrote: > > > 2016-04-17 18:13 GMT+02:00 Cecil Westerhof : > > > > > 2016-04-17 17:13 GMT+02:00 Keith Medcalf : > > > The strange thing is that the blob variant takes a lot of time now > also. > > >

[sqlite] Is it possible that dropping a big table takes very long

2016-04-17 18:13 GMT+02:00 Cecil Westerhof : > 2016-04-17 17:13 GMT+02:00 Keith Medcalf : > The strange thing is that the blob variant takes a lot of time now also. > First it took only 4? hour, now it is already busy for eight hours and only > has come to 8.9E7. > > 14:36:01: Inserted

[sqlite] Is it possible that dropping a big table takes very long

2016-04-17 17:13 GMT+02:00 Keith Medcalf : > > Perfectly linear. The time waster in creating the records is the index > with the completely separate copy of all the data and the native primary > key (record number) into a duplicate structure (the index btree). Creating > the index and the base

[sqlite] Is it possible that dropping a big table takes very long

On 17 Apr 2016, at 5:13pm, Cecil Westerhof wrote: > Or is this normal > in Java programs? Yes. You're discovering that Java is rubbish. 'futex' for Java is what most environments call 'mutex' and Java doesn't do locking well. It's this which is causing your delays, not SQLite or anything

[sqlite] Is it possible that dropping a big table takes very long

On Sun, Apr 17, 2016 at 1:44 PM, Cecil Westerhof wrote: > 2016-04-17 18:13 GMT+02:00 Cecil Westerhof : > > > 2016-04-17 17:13 GMT+02:00 Keith Medcalf : > > The strange thing is that the blob variant takes a lot of time now also. > > First it took only 4? hour, now it is already busy for eight

[sqlite] Is it possible that dropping a big table takes very long

2016-04-17 12:03 GMT+02:00 Simon Slavin : > > On 17 Apr 2016, at 10:38am, Cecil Westerhof > wrote: > > > I start with a: > >? > > > > ?conn.setAutoCommit(false); > > but that is not the same? > > Yes, that does the same as BEGIN ... END. At least, according to the > documentation it does. >

[sqlite] Is it possible that dropping a big table takes very long

2016-04-17 10:13 GMT+02:00 Rob Willett : > I do not have the whole thread for what you reported but I did read > somebody ask if you have put your inserts between a BEGIN/END transaction. > That will make a massive difference to your speed. Also I?m unclear as to > how Java fits in all of this.

[sqlite] Is it possible that dropping a big table takes very long

625 sys 0.984375 > -Original Message- > From: sqlite-users-bounces at mailinglists.sqlite.org [mailto:sqlite-users- > bounces at mailinglists.sqlite.org] On Behalf Of Cecil Westerhof > Sent: Sunday, 17 April, 2016 06:44 > To: SQLite mailing list > Subject: Re: [sqlite] Is it possible th

[sqlite] Is it possible that dropping a big table takes very long

On 17 Apr 2016, at 10:38am, Cecil Westerhof wrote: > I start with a: >? > > ?conn.setAutoCommit(false); > but that is not the same? Yes, that does the same as BEGIN ... END. At least, according to the documentation it does. But you caused me to look up how the JDBC works, especially

[sqlite] Is it possible that dropping a big table takes very long

2016-04-17 4:16 GMT+02:00 R Smith : > > > On 2016/04/16 9:25 PM, Cecil Westerhof wrote: > >> 2016-04-16 20:36 GMT+02:00 R Smith : >> >> I am filling the database again, but now with text UUID instead of blob >> UUID. That takes a ?little? more time. When it is filled I try again. >> > > Don't

[sqlite] Is it possible that dropping a big table takes very long

2016-04-17 1:03 GMT+02:00 Keith Medcalf : > > Have another problem also. My CPU is about 15%, but the load average is > > also about 15. (This is on a Linux system.) This results (sometimes) in a > > very sluggish system. Can the load be a SQLite problem, or is it a Java > > problem? (When the

[sqlite] Is it possible that dropping a big table takes very long

Cecil,, Linux reporting 8 cores is due to hyper threading on the four cores. Thats normal. One of the cores reporting a high usage is normal if you have single threaded app that simply cannot be moved, e.g. many perl programs exhibit this behaviour. Thats fine and to be expected. I do not

[sqlite] Is it possible that dropping a big table takes very long

On 2016/04/16 9:25 PM, Cecil Westerhof wrote: > 2016-04-16 20:36 GMT+02:00 R Smith : > > I am filling the database again, but now with text UUID instead of blob > UUID. That takes a ?little? more time. When it is filled I try again. Don't forget to copy the DB file once it is populated, that

[sqlite] Is it possible that dropping a big table takes very long

2016-04-16 21:44 GMT+02:00 Rob Willett : > If you have a load average of 15 then that normally means you have a > massively overloaded Linux box. I don?t know your system but I get worried > around a load average of 3-4 on our boxes. Load Average is a very crude > measurement but a high number

[sqlite] Is it possible that dropping a big table takes very long

2016-04-16 20:36 GMT+02:00 R Smith : > > > On 2016/04/16 3:39 PM, Cecil Westerhof wrote: > >> 2016-04-16 14:52 GMT+02:00 R Smith : >> >> Let me try the 100 million rows, this may take some time - I will post >>> again when it is done. >>> >>> ?I am curious. >> > > Well, here it is then,

[sqlite] Is it possible that dropping a big table takes very long

Cecil, If you have a load average of 15 then that normally means you have a massively overloaded Linux box. I don?t know your system but I get worried around a load average of 3-4 on our boxes. Load Average is a very crude measurement but a high number tends to be bad. If your CPU is only

[sqlite] Is it possible that dropping a big table takes very long

On 16 Apr 2016, at 8:25pm, Cecil Westerhof wrote: > I am filling the database again, but now with text UUID instead of blob > UUID. That takes a ?little? more time. When it is filled I try again. I assume you're doing many INSERT commands between BEGIN and END. > Have another problem also. My

[sqlite] Is it possible that dropping a big table takes very long

On 2016/04/16 3:39 PM, Cecil Westerhof wrote: > 2016-04-16 14:52 GMT+02:00 R Smith : > >> Let me try the 100 million rows, this may take some time - I will post >> again when it is done. >> > ?I am curious. Well, here it is then, 100-million rows: The INSERT took a lot of time, near 5 hours,

[sqlite] Is it possible that dropping a big table takes very long

> Have another problem also. My CPU is about 15%, but the load average is > also about 15. (This is on a Linux system.) This results (sometimes) in a > very sluggish system. Can the load be a SQLite problem, or is it a Java > problem? (When the program is not running, the load average is a lot >

[sqlite] Is it possible that dropping a big table takes very long

2016-04-16 16:19 GMT+02:00 R Smith : > > > On 2016/04/16 4:09 PM, Cecil Westerhof wrote: > >> One strange thing the commandline and DB Browser are using ?3.8.10.2 >> while Java is using 3.8.11. >> > > Your command-line is simply outdated - you can download the newest from >

[sqlite] Is it possible that dropping a big table takes very long

On 2016/04/16 4:09 PM, Cecil Westerhof wrote: > One strange thing the commandline and DB Browser are using ?3.8.10.2 > while Java is using 3.8.11. Your command-line is simply outdated - you can download the newest from http://sqlite.org/download/ DB-Browser might have a newer version also,

[sqlite] Is it possible that dropping a big table takes very long

2016-04-16 16:00 GMT+02:00 R Smith : > > > On 2016/04/16 3:39 PM, Cecil Westerhof wrote: > >> 2016-04-16 14:52 GMT+02:00 R Smith : >> >>-- 2016-04-16 14:44:55.054 | [Success]Script Success. >>> >>> As you can see, the INSERT obviously takes some time (even more-so if the >>> CHECK

[sqlite] Is it possible that dropping a big table takes very long

2016-04-16 15:41 GMT+02:00 Simon Slavin : > > > ?How can I get the journal mode in Jav?? > > With DB Browser I get Delete. > > But when I in sqlite3 give: > >PRAGMA schema.journal_mode; > > I get: > >Error: unknown database schema > > That is not well explained. Try just > > PRAGMA

[sqlite] Is it possible that dropping a big table takes very long

and a Java program. >> I just tried it with a table of 1E7 elements. That was dropped in about 13 >> seconds. >> I will try it again with 1E8 elements, but it takes 4? hours to generated. >> Is it possible that SQLite has trouble dropping very large tables? It was >> 5

[sqlite] Is it possible that dropping a big table takes very long

2016-04-16 14:51 GMT+02:00 Simon Slavin : > > On 16 Apr 2016, at 10:59am, Cecil Westerhof > wrote: > > > I first had a table with 1E8 elements. When > > trying to drop this it looked like SQLite got hung. > > Please tell us which version of SQLite and which journal mode you're using. > ?I work

[sqlite] Is it possible that dropping a big table takes very long

was dropped in about 13 > seconds. > I will try it again with 1E8 elements, but it takes 4? hours to generated. > Is it possible that SQLite has trouble dropping very large tables? It was > 5.2 GB. With 1E7 elements the table is 512 MB. > > The definition of the table: > CREATE T

[sqlite] Is it possible that dropping a big table takes very long

On 16 Apr 2016, at 2:32pm, Cecil Westerhof wrote: > ?I work with Java. With: >SELECT SQLITE_VERSION() > I get: >3.8.11? Thanks. > ?How can I get the journal mode in Jav?? > With DB Browser I get Delete. > But when I in sqlite3 give: >PRAGMA schema.journal_mode; > I get: >

[sqlite] Is it possible that dropping a big table takes very long

On 16 Apr 2016, at 10:59am, Cecil Westerhof wrote: > I first had a table with 1E8 elements. When > trying to drop this it looked like SQLite got hung. Please tell us which version of SQLite and which journal mode you're using. My guess is that the operations for 1e7 rows fit in one of the

[sqlite] Is it possible that dropping a big table takes very long

, but it takes 4? hours to generated. Is it possible that SQLite has trouble dropping very large tables? It was 5.2 GB. With 1E7 elements the table is 512 MB. The definition of the table: CREATE TABLE testUniqueUUID ( UUIDblob, PRIMARY KEY(UUID) CHECK(TYPEOF(UUID) = 'blob

[sqlite] Is it possible that keep SQLite in normal lockingmodewithout mmap?

at bigfraud.org ???:General Discussion of SQLite Databasesqlite-users at mailinglists.sqlite.org :2015?10?9?(??)?20:38 ??:Re: [sqlite] Is it possible that keep SQLite in normal lockingmodewithout mmap? On 9 Oct 2015, at 1:29pm, sanhua.zh sanhua.zh at foxmail.com wrote: 2. multithread-reading

[sqlite] Is it possible that keep SQLite in normal locking modewithout mmap?

may increase theprobability of database corruption. While my app has a huge number of users(more than ten-million), I have to consider more about robustness. see also: http://www.sqlite.org/wal.html#noshm http://www.sqlite.org/pragma.html#pragma_locking_mode As a conclusion, I wonder, in SQLite

[sqlite] Is it possible that keep SQLite in normal lockingmodewithout mmap?

On 9 Oct 2015, at 1:46pm, sanhua.zh wrote: > It?s a mistake ofexpression. > I mean, > 1. readconcurrently indifferent threads. > or > 2. write in one thread andread inother threads. Okay. That is what WAL mode does very well. There's nothing better you can do for this than to use WAL mode.

[sqlite] Is it possible that keep SQLite in normal locking modewithout mmap?

On 9 Oct 2015, at 1:29pm, sanhua.zh wrote: > 2. multithread-reading-and-writing, not serial It is not possible for two different operations, whether different threads or different processes, to write to a database at the same time. No matter what system you use this just isn't possible. To

[sqlite] Is it possible to have query planner use FTS Index for ORDER BY

-users-boun...@mailinglists.sqlite.org [mailto:sqlite-users-bounces at mailinglists.sqlite.org] On Behalf Of David Waters Sent: Thursday, August 20, 2015 8:58 PM To: General Discussion of SQLite Database Subject: Re: [sqlite] Is it possible to have query planner use FTS Index for ORDER BY Thanks Dan

[sqlite] Is it possible to have query planner use FTS Index for ORDER BY

Of David Waters Sent: Thursday, August 20, 2015 4:47 PM To: General Discussion of SQLite Database Subject: Re: [sqlite] Is it possible to have query planner use FTS Index for ORDER BY Sorry. I should have specified that that 'udate' is one of the indexed columns of the FTS4 table main. The goal is to do

[sqlite] Is it possible to have query planner use FTS Index for ORDER BY

On 08/20/2015 12:38 PM, David Waters wrote: > I have a large FTS4 table (around 200 million rows and growing). A simple > query (SELECT * FROM main WHERE main MATCH 'data') returns in less than a > second. However, if an ORDER BY is added (SELECT * FROM main WHERE main > MATCH 'data' ORDER BY

[sqlite] Is it possible to have query planner use FTS Index for ORDER BY

gt; To: General Discussion of SQLite Database > Subject: Re: [sqlite] Is it possible to have query planner use FTS Index > for > ORDER BY > > Thanks Dan and Vladimir. A combination of the two approaches is required. > I'll detail it here for future reference: > > Using the sub que

[sqlite] Is it possible to have query planner use FTS Index for ORDER BY

main WHERE main MATCH 'data') > ORDER BY udate > > cheers, > > > -Original Message- > From: sqlite-users-bounces at mailinglists.sqlite.org > [mailto:sqlite-users-bounces at mailinglists.sqlite.org] On Behalf Of David > Waters > Sent: Thursday, August 20, 20

[sqlite] Is it possible to have query planner use FTS Index for ORDER BY

Sorry. I should have specified that that 'udate' is one of the indexed columns of the FTS4 table main. The goal is to do a FTS query and be able to ensure the results are ordered the same each time (via the ORDER BY). It seemed at first to me that the FTS index contains what is needed for the

[sqlite] Is it possible to have query planner use FTS Index for ORDER BY

I have a large FTS4 table (around 200 million rows and growing). A simple query (SELECT * FROM main WHERE main MATCH 'data') returns in less than a second. However, if an ORDER BY is added (SELECT * FROM main WHERE main MATCH 'data' ORDER BY udate) it will never return (after 20 mins, I canceled

Re: [sqlite] Sqlite problem possible bug

On 2015/01/07 12:13, The Responsa Project wrote: To Whom it amy concern I am trying to use SQLITE and the like statement with wildcards and hebrew when I put in an english string it works correctly, such as Select * from dbname where colname like '%123%' I will get all the entries from

Re: [sqlite] Sqlite problem possible bug

On 1/7/15, The Responsa Project wrote: > To Whom it amy concern > > > I am trying to use SQLITE and the like statement with wildcards and hebrew > > when I put in an english string it works correctly, such as > > Select * from dbname where colname like '%123%' > > I will

Re: [sqlite] Sqlite problem possible bug

How about to use dynamic binding? For example, is your SQL(SELECT * from dbname where colname like '%אב%'), use '?' instead of 'אב'. In my guess, 'אב' can have same ASCII code of wildcard(%). Full SQL can be as like as follows. SELECT * from dbname where colname like '%?%' To do this, you need

[sqlite] Sqlite problem possible bug

To Whom it amy concern I am trying to use SQLITE and the like statement with wildcards and hebrew when I put in an english string it works correctly, such as Select * from dbname where colname like '%123%' I will get all the entries from that column that contain 123 anywhere in the column.

Re: [sqlite] maintaining order state for custom functions in sqlite: is it possible to insure that callback gets records in "ORDER BY" order?

john soprych wrote: > Is there a good way to create functions in sqlite where you can insure that > your function callback will be called in order? No. Your best bet is writing the query in such a way that the function is applied to an already ordered sequence: SELECT myfunc(x) FROM (SELECT

[sqlite] maintaining order state for custom functions in sqlite: is it possible to insure that callback gets records in "ORDER BY" order?

Is there a good way to create functions in sqlite where you can insure that your function callback will be called in order? The api currently has support for purely functional functions and result set aggregates, but neither require that their respective callbacks are called in sort order

Re: [sqlite] Is it possible to see timeline for given branch (or eventag)?

Oops! That was meant for the fossil group, sorry! -Original Message- From: Tony Papadimitriou Sent: Thursday, March 27, 2014 7:26 PM To: General Discussion of SQLite Database Subject: [sqlite] Is it possible to see timeline for given branch (or eventag)? When I give the command

<    1   2   3   4   5   >