Re: [sqlite] How to achieve fastest possible write performance for a strange and limited case

On Fri, Mar 29, 2013 at 8:17 PM, Jeff Archer < jsarc...@nanotronicsimaging.com> wrote: > I could write directly to a file myself. But I would need to provide some > minimal indexing, some amount of housekeeping to manage variable > sized BLOBS and some minimal synchronization so that multiple

Re: [sqlite] How to achieve fastest possible write performance for a strange and limited case

In case you haven't seen this: http://www.sqlite.org/intern-v-extern-blob.html On Friday, 29 March, 2013 at 13:52, Jeff Archer wrote: > On Fri, Mar 29, 2013 at 4:46 PM, Richard Hipp (mailto:d...@sqlite.org)> wrote: > > On Fri, Mar 29, 2013 at 4:41 PM, Michael Black

Re: [sqlite] How to achieve fastest possible write performance for a strange and limited case

On Fri, Mar 29, 2013 at 4:46 PM, Richard Hipp wrote: > On Fri, Mar 29, 2013 at 4:41 PM, Michael Black wrote: > >> I think many people would tell you not to store your images in your >> database. >> Just store a filepath to them. >> That will speed things up

Re: [sqlite] Performance with journal_mode = off

>On Fri, Mar 29, 2013 at 4:05 PM, Simon Slavin wrote: > >No. The two things have nothing to do with one-another. Transactions are >about grouping changes together >so that either they all happen or none happen. Journalling is about surviving >through crashes and

Re: [sqlite] How to achieve fastest possible write performance for a strange and limited case

On Fri, Mar 29, 2013 at 4:41 PM, Michael Black wrote: > I think many people would tell you not to store your images in your > database. > Just store a filepath to them. > That will speed things up quite a bit and even possibly prevent having to > use an SSD. > > With the

Re: [sqlite] How to achieve fastest possible write performance for a strange and limited case

I think many people would tell you not to store your images in your database. Just store a filepath to them. That will speed things up quite a bit and even possibly prevent having to use an SSD. With the filepath your processing apps can use file locking too if you need it. -Original

Re: [sqlite] How to achieve fastest possible write performance for a strange and limited case

Pavel Ivanov wrote: > On Fri, Mar 29, 2013 at 12:17 PM, Jeff Archer > wrote: >> I have previously made an apparently bad assumption about this so now I >> would like to go back to the beginning of the problem and ask the most >> basic

Re: [sqlite] How to achieve fastest possible write performance for a strange and limited case

On Fri, Mar 29, 2013 at 12:17 PM, Jeff Archer wrote: > I have previously made an apparently bad assumption about this so now I > would like to go back to the beginning of the problem and ask the most > basic question first without any preconceived ideas. > > This

Re: [sqlite] Performance with journal_mode = off

On 29 Mar 2013, at 6:42pm, Jeff Archer wrote: > But shouldn't transactions be disabled when journal_mode = off? No. The two things have nothing to do with one-another. Transactions are about grouping changes together so that either they all happen or none

Re: [sqlite] How to achieve fastest possible write performance for a strange and limited case

On 29 Mar 2013, at 7:17pm, Jeff Archer wrote: > This use case is from an image processing application. I have a large > amount of intermediate data (way exceeds physical memory on my 24GB > machine). So, I need to store it temporarily on disk until getting to

Re: [sqlite] Performance with journal_mode = off

>Date: Thu, 28 Mar 2013 14:13:51 +0100 >From: ibrahim > >... You should compare > >a) Journal mode=on w/wo single transaction >b) Journal mode=off w/wo single transaction So, this means I can use transaction when I have journal_mode = off? I did not understand that

[sqlite] How to achieve fastest possible write performance for a strange and limited case

I have previously made an apparently bad assumption about this so now I would like to go back to the beginning of the problem and ask the most basic question first without any preconceived ideas. This use case is from an image processing application. I have a large amount of intermediate data

Re: [sqlite] Performance with journal_mode = off

>From: "James K. Lowden" >To: sqlite-users@sqlite.org > > Your experiment is telling you different: transaction control costs more than I/O. But shouldn't transactions be disabled when journal_mode = off? Maybe that is a faulty assumption. If so, what is the point of

Re: [sqlite] Install sqlite-netFx40-setup-bundle silently

Am 27.03.2013 10:21, schrieb Jeff Williams: Is it possible and if so how to install sqlite-netFx40-setup-bundle in a silent mode. I would like to do the install as part of a software package but would prefer the users are not presented with the install screens. Also what would be the easiest

[sqlite] SQLite Version 3.7.16.1

SQLite version 3.7.16.1 is now available on the SQLite website http://www.sqlite.org/ Version 3.7.16.1 is a patch release with only minor changes from version 3.7.16. The reason for this patch release is to fix a bug in the query optimizer enhancements that were part of version 3.7.15.

Re: [sqlite] TCL Test failures on ARM

On 03/29/2013 04:35 PM, Bk wrote: The perror("ftruncate") is printing ftruncate: : File too large . i have a 2GB card in the embedded device with 50% mem free. Seems like EFBIG. What value is actually being passed as the second argument to the system ftruncate() call? Does the test pass if

Re: [sqlite] TCL Test failures on ARM

The perror("ftruncate") is printing ftruncate: : File too large . i have a 2GB card in the embedded device with 50% mem free. Below is the output window shows when the test executed. sysfault-2.setup... Ok ftruncate: : File too large ftruncate: : File too large ftruncate: : File too large

Re: [sqlite] Performance with journal_mode = off

On 28.03.2013 14:03, Jeff Archer wrote: On Thu, Mar 28, 2013 at 8:24 AM, ibrahim wrote: On 28.03.2013 13:09, Jeff Archer wrote: On Wed, Mar 27, 2013 at 6:35 PM, Simon Slavin wrote: Reasonable figures. With 5764 writes to the disk in