Re: [sqlite] Journalling
That's not exactly correct. On modern systems, unless you exhaust memory you'll never hit the journal (in which case you'd need a journal- but read on). What you really want is to run the database without syncing. You _can_ comment this code out in os.c- but I wouldn't recommend it. The time is so minimal that you're not likely to gain much. You can find out exactly how much you'll gain by testing against a ramdisk- AFAIK, modern systems don't do anything special when fsync() occurs on a file in a ramdisk, although I suppose that strictly isn't very portable... On Mon, 2003-10-27 at 02:16, v t wrote: > I am trying to use sqlite in a context where I will be using it to > store some configuration about a system. I want to try to minimize the > disk access. Since journalling uses a file on the disk, I wanted to > turn it off. I am not worried about rolling back the database to a > known state in case of some failure. > > vt > > "Mrs. Brisby" <[EMAIL PROTECTED]> wrote: > On Thu, 2003-10-23 at 19:46, v t wrote: > > Hi, > > > > How do I turn journalling OFF? > > Why do you want to? What exactly are you trying to accomplish? > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > __ > Do you Yahoo!? > Exclusive Video Premiere - Britney Spears - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sqlite] new mail list/digest
will someone have mercy on an ignorant beginner? The old yahoo digest could be saved as a single text file, which I did, trying to build a sort of 'unofficial FAQ' for myself. The new digest, will only save the 'contents' page, and each post must be saved individually. Does someone know of a way I can save the entire digest at one time? Is this caused by the new mailing list format, or is it a yahoo matter? any help will be appreciated. John Holbrook __ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] Journalling
Hello, I am aware that: 1) Reading from the database doesnt involve opening a journal file. 2) Writing (INSERT, UPDATE etc) to the database opens a journal file on the disk. 3) PRAGMA default_synchronous = OFF; (0) is to turn on sync ON or OFF. I am writing to a database file every 200ms on a compact flash. My understanding of the PRAGMA default_synchronous = OFF; (0) was that it is used for flushing the database contents on each write or doing it at the end of a database transaction. (simlilar to doing a buffered I/O eg fwrite, fflush or doing a unbuffered I/O like write). And my understanding of journalling is that it is used to rollback any changes to the database in case of failures during a transaction. I am no expert on journalling so I could be wrong. So I was just tailoring SQLite to my needs and not trying to throw away the use of a very useful feature. ( I may decide to use it when I need it again). vt [EMAIL PROTECTED] wrote: Hello, v t 27/10/2003 05:16 PM To: "Mrs. Brisby" cc: sqlite Subject: Re: [sqlite] Journalling > I am trying to use sqlite in a context where I will be using it to store some configuration about a system. I want to try to minimize the disk access. Since journalling uses a file on the disk, I wanted to turn it off. I am not worried about rolling back the database to a known state in case of some failure. You're not worried about your database becoming corrupted and all your data being destroyed? It doesn't sound like you like your data very much... ;) This is a question that pops up on the list every so often, and there have been some good reasons for it. Well. One comes to mind, and that's the use of flash memory in embedded devices. When you don't want to write to your media too many times you might find that it's better to turn off journalling and risk the consequences... perhaps make regular backups... rather than write to the media too often. The problem is that most people don't know what they're talking about when they ask how to turn journalling off. They don't understand when the journal gets written in the first place and they don't understand which operations they're performing that aren't affected by journalling. They haven't read the list archives, and they patently haven't read the manual, because it's listed under the pragma section of http://www.sqlite.org/lang.html. This is why when you ask the question on this list you get the response "Well I know you've asked how to turn off journalling, but what do you actually want to achieve by this and what alternatives have you considered?" You haven't yet given an explination that makes sense to me, so in the spirit of RTFM I'll leave you to find the exact manual reference yourself. I think it's worth you understanding, though, that journalling doesn't occur when you're only querying the database. It only happens when you modify the database. Using transactions while modifying the database is not only a good idea for data integrity, it also makes the overhead associated with synching the file to disk almost disappear so there's usually no need at all to turn off journalling. Given all of this, if you still can't find the exact spot in the manuals to turn this off yourself perhaps you could offer a more complete discussion about the nature of your database and your access to it. You'd be well advised to discuss the alternatives you have considered so that the gentle list members will feel more compelled to answer your question directly. Benjamin --Premature optimisation is the root of all evil - Do you Yahoo!? Exclusive Video Premiere - Britney Spears
Re: [sqlite] Performance benchmarking
Monday, October 27, 2003, 9:22:57 AM, D. Richard Hipp wrote: > If you think about how a disk driver works, you'll quickly realize > that to truly commit a transaction to the disk surface requires at > least one revolution of the platter. So for a 5400 RPM disk drive, > you will get (at most) 90 transactions per second. SQLite gets you > very close to this number. The INSERT times reported back by other > database engines often exceed this number, which tells me they are > not really committing the changes to the disk surface before they > return. Database servers that use Write Ahead Logs (WALs : log files that store both redo and undo information, as well as transaction checkpoint and commit status) can consider the data "written to disk" as soon as a commit record is appended to the WAL. The update of the primary on-disk data structures can proceed lazily since (a) other transactions will use the in-memory (cached) copy of the data structures first, and (b) any crash will replay the WAL and recover the on-disk data structures. So, database servers using WAL can commit transactions as fast as they can be appended to a sequential log on disk; if the driver is smart and has enough writes enqueued, this is as fast as the disk can take data: no waiting for disk rotation. e - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sqlite] newbie: Alter Table
hello everybody: I am newbie to both sql and sqlite and i am testing sqlite for a specifc multi-variate application for in-memory database. >From the documentation I see that it is not possible to do alter table and add new columns. But the documentation mentions deleting and adding the table with new features. I have two questions in this regard. 1. Can anyone send me a sample c++ with which I can fake 'alter table add' and 'alter table delete' ... 2. is there any plans to add this in future ? Thanks a lot Sathya Krishnamurthy ISE AG - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] Making sqlite support unicode?
On Sun, 26 Oct 2003 23:36:55 -0500 "Mrs. Brisby" <[EMAIL PROTECTED]> wrote: > It's good to use null-terminated in many cases; especially in collating > and sorting. It helps to understand that in those cases you stop > processing _after_ you see the terminator (and treat the terminator as > it is: zero.) Collating involves with length. If data length is known prior to scanning data, in some cases you can skip it if it doesn't match without scanning data body. It helps to understand that in those cases you stop processing _before_ you see the terminator or anything else. > UTF-16 is NOT used in HFS+. HFS+ still uses ASCII with some "tricks". > UFS is what's "preferred" in MacOS X, and it doesn't use UTF-16 either. > UTF-16 isn't what we're talking about anyway, it's UCS16. Thank you for your clarification, I'd like to hear more about that imaginative "tricks", but it's OT I'm afraid. MacOS X uses "Unicode" as its native encoding. In Unicode encoding the most used in MacOS X is UTF-16. Only to call BSD API it uses UTF-8. It's kind of hybrid, but UTF-8 is just used for compatibility to Unix parts in MacOS X, and other non-Unix pieces in MacOS X, which is why MacOS X is Mac, is using UTF-16 internally, including Carbon, Cocoa and ATSUI. For HFS+, from Apple's Technical Note TN2078 (Migrating to FSRefs & long Unicode names from FSSpecs): http://developer.apple.com/technotes/tn2002/tn2078.html "How file names are encoded HFS+ disks store file names as UTF-16 in an Apple-modified form of Normalization Form D (decomposed). This form excludes certain compatibility decompositions and parts of the symbol blocks, in order to assure round-trip of file names to Mac OS encodings (applications using the HFS APIs assume they get the same bytes out that they put in). In Mac OS X 10.2, the decomposition rules used were changed from Unicode 2.0.x (based on an intermediate draft) plus the above-mentioned Apple modifications, to Unicode 3.2 plus the above-mentioned Apple modifications. The Unicode Consortium has committed to not changing the decomposition rules after Unicode 3.2, so we shouldn't have to do this again. The change from 2.0.x to 3.2 was necessary because A) lots of new decompositions had been added, and B) the 2.0.x data was full of errors. Other file systems use different storage formats. UFS disks use UTF-8, HFS disks use Mac OS encodings. AFP (AppleShare) uses Mac OS encodings prior to 3.0, and UTF-16 for 3.0 or later. " -- KL - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] Performance benchmarking
> Danny Reinhold wrote: > > DRH tested inserts with and without transactions on several > > DBMSs. PostgreSQL and MySQL where faster _without_ > > explicit transactions. > > That looks a bit strange to me... > If you are referring to Test 1 and Test 2 at http://www.sqlite.org/speed.html, > please look again. The transaction-less test (Test 1) only inserts 1000 > records, whereas the transaction test (Test 2) inserts 25000 records. So > even though the elapse time is a little more for some engines on the second > test, they are doing 25 times more work, so they are really quite a bit > faster. Ah yes, I see. Sorry. - Danny -- Danny Reinhold Reinhold Software & Services - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] Performance benchmarking
Danny Reinhold wrote: DRH tested inserts with and without transactions on several DBMSs. PostgreSQL and MySQL where faster _without_ explicit transactions. That looks a bit strange to me... If you are referring to Test 1 and Test 2 at http://www.sqlite.org/speed.html, please look again. The transaction-less test (Test 1) only inserts 1000 records, whereas the transaction test (Test 2) inserts 25000 records. So even though the elapse time is a little more for some engines on the second test, they are doing 25 times more work, so they are really quite a bit faster. -- D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] Performance benchmarking
Hi! > I am putting finishing touches on quite a large application that uses Sqlite > for the single user edition. My experience has been that inserting data is > quite slow in comparison to most other dbs. All other operations are faster > than any other db. It appears that Sqlite is highly optimized for SELECT, > UPDATE, and DELETE, but INSERT is a bit slow. > > Although the insertion speed of Sqlite is plenty fast for a single user app > or a medium sized web app. > > If my instincts and research is correct, most other databases simply cache > the transactions in memory to give the appearance that they are inserting > very quickly, but the truth is they are probably not quite as safe as Sqlite > since it writes the data to disk immediately upon receipt. This appears to > be the bottleneck. No, all DBMSs that support transactions ensure that the data has been written to disk when a commit is performed. The technical details are very different of course, but all systems ensure that commited data is on the disk. SQLite doesn't write data to the disk when you insert rows, but when you commit the changes - so it shouldn't be slower than other systems. DRH wrote in his answer that other DBMSs don't really write data to the disk (fsync()) as you guessed. But I cannot believe that - and I am aware of some discussions on the Firebird and PostgresSQL mailing lists months (or years?) ago about this issue... These systems are carefully designed to guarantee atomic commits and to ensure that commited data is safe (to the degree that the operating system and the disk driver can guarantee). I also cannot believe that major systems like Oracle or Informix which I think are designed very well don't really save the data correctly... BTW: You say that an update query is fast, but an insert is not. That is strange, because both statements require a commit. And when the commit is the bottleneck it should be present in both cases... If your inserts are slow, my first guess is that you did not put them in a single large transaction. This has been discussed on this list some thousand times, but anyhow - this seems to be the most often made error... DRH's speed comparision shows that insert statements are faster than with other dbmss when a transaction is used and slower if not... What I don't understand is that other systems don't show this effect. DRH tested inserts with and without transactions on several DBMSs. PostgreSQL and MySQL where faster _without_ explicit transactions. That looks a bit strange to me... The effect in PostgreSQL isn't very large and maybe you can explain that with the complex transaction handling in PostgrelSQL. But MySQL looks really strange to me (I have never used MySQL - now I know why ;-))... > I would be interested in knowing more about the internals of Sqlite that > make it perform without having to do a major study of the code. I have read > the architecture books on most other major databases, but not on Sqlite. : -) Read the code - it is very, very well documented - and short enough to be understood! - Danny -- Danny Reinhold Reinhold Software & Services - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] Performance benchmarking
Jonas Forsman / Axier.SE wrote: Has anyone tested and concluded that sqlite is faster for small databases (<5000 records) so I don't sit here in vain, trying to optimize for something that just can't be done? http://www.sqlite.org/speed.html. -- D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FW: [sqlite] Performance benchmarking
Allan Edwards wrote: If my instincts and research is correct, most other databases simply cache the transactions in memory to give the appearance that they are inserting very quickly, but the truth is they are probably not quite as safe as Sqlite since it writes the data to disk immediately upon receipt. This appears to be the bottleneck. I think you are correct. If you think about how a disk driver works, you'll quickly realize that to truly commit a transaction to the disk surface requires at least one revolution of the platter. So for a 5400 RPM disk drive, you will get (at most) 90 transactions per second. SQLite gets you very close to this number. The INSERT times reported back by other database engines often exceed this number, which tells me they are not really committing the changes to the disk surface before they return. I would be interested in knowing more about the internals of Sqlite that make it perform without having to do a major study of the code. I have read the architecture books on most other major databases, but not on Sqlite. : - Allan: If you will call me (at the number below) and explain the internals of other major database engines, I'll explain everything you care to know about SQLite. -- D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
FW: [sqlite] Performance benchmarking
I am putting finishing touches on quite a large application that uses Sqlite for the single user edition. My experience has been that inserting data is quite slow in comparison to most other dbs. All other operations are faster than any other db. It appears that Sqlite is highly optimized for SELECT, UPDATE, and DELETE, but INSERT is a bit slow. Although the insertion speed of Sqlite is plenty fast for a single user app or a medium sized web app. If my instincts and research is correct, most other databases simply cache the transactions in memory to give the appearance that they are inserting very quickly, but the truth is they are probably not quite as safe as Sqlite since it writes the data to disk immediately upon receipt. This appears to be the bottleneck. I would be interested in knowing more about the internals of Sqlite that make it perform without having to do a major study of the code. I have read the architecture books on most other major databases, but not on Sqlite. : - ) Thanks, Allan -Original Message- From: Jonas Forsman / Axier.SE [mailto:[EMAIL PROTECTED] Sent: Monday, October 27, 2003 3:27 AM To: [EMAIL PROTECTED] Subject: [sqlite] Performance benchmarking Hi, I have recently converted a "problem application" from MS-Access to SQLite in Visual Basic but the performance is really worse then with Access. I have not changed much in the application code except for a few things that should be in favour to sqlite, like implementing a second "in memory" database for temporary data and disc based write-to db. Has anyone tested and concluded that sqlite is faster for small databases (<5000 records) so I don't sit here in vain, trying to optimize for something that just can't be done? Inserts are done in a transaction (extremely good prestanda here), selects are indexed (could this be a problem in a table with 2-3 000 records?) by adding too much overhead compared to a non-indexed, sequential, search? regards /Jonas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] SQLite in Web application
On 27 Oct 2003, at 5:20, Greg Obleshchuk wrote: So if anyone is using SQLite in a web application that is used by lots of people I would love to here about any problems or just of your success. I have a *very* large scale web application using SQLite as a backend, but we segment it sensibly. Cross-user information is stored in SQL Server, and per-user information is stored in SQLite. That allows us to scale very very well (to places even SQL Server couldn't touch). We don't suffer the usual concerns about locking in a web app because multiple users are talking to different SQLite DBs. Matt. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] Sqlite databases file extension
Hi again, > > The file extension doesn't matter. > I think it matters. I meant: SQLite does not force you to use a specific extension. It will work with .sqlite, .db, . files and even with files that don't have an extension. So technically the extension doesn't matter... > > You should either use an extension that explains what kind of data > > is stored in the file (for example .conf if it is a configuration database) > > or an extension that doesn't conflict with extensions of other applications. > > (So you can configure a default viewer for you database files etc. on > > platforms that utilize file extensions this way.) > > > > .sqlite. .sdb, .db or .db are good choices. > > I get your point. But not having a common extension makes it more difficult > to recognize a sqlite db from other files, especially if you want to share > your files. In a desktop environment, an extension is useful for opening > files with the proper application and for displaying a specific icon for > that files. > > A recommendation would be nice IMO. In most cases an SQLite database is usefull only in the context of a specific application. So there is no reason for an extension that indicates a file as an SQLite database. If you use an extension that is specific for your application you can register your application as the file's native application. Only SQLite database management applications can be usefull for all SQLite databases. But those applications are not used by the users of your SQLite application, but by its developer - and he knows that a file is an SQLite database file. So I think we don't need an offical recommendation for file name extensions, but maybe a recommendation for extensions that should NOT be used. For example I think .db isn't a good choice, because other applications probably already use that. All well known extensions aren't good choices... - Danny -- Danny Reinhold Reinhold Software & Services - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] Sqlite databases file extension
<[EMAIL PROTECTED]> wrote : > Hi, > >> Is there a recommended file extension for sqlite database files ? If not, >> are there any suggestions or a commonly used extension ? What about > .sqlite >> or .db ? > The file extension doesn't matter. I think it matters. > You should either use an extension that explains what kind of data > is stored in the file (for example .conf if it is a configuration database) > or an extension that doesn't conflict with extensions of other applications. > (So you can configure a default viewer for you database files etc. on > platforms that utilize file extensions this way.) > > .sqlite. .sdb, .db or .db are good choices. I get your point. But not having a common extension makes it more difficult to recognize a sqlite db from other files, especially if you want to share your files. In a desktop environment, an extension is useful for opening files with the proper application and for displaying a specific icon for that files. A recommendation would be nice IMO. -- Bertrand Mansion Mamasam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] Performance benchmarking
> select * from mytable where a like 'b%'; > may be slow - even if a is an indexed column. > select * from mytable where a >= 'ba' and a <= 'bz'; > may be very fast. Ahhh, sorry, I meant: select * from mytable where a > 'a' and a < 'c'; should be better... - Danny -- Danny Reinhold Reinhold Software & Services - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] Sqlite databases file extension
Hi, > Is there a recommended file extension for sqlite database files ? If not, > are there any suggestions or a commonly used extension ? What about .sqlite > or .db ? The file extension doesn't matter. You should either use an extension that explains what kind of data is stored in the file (for example .conf if it is a configuration database) or an extension that doesn't conflict with extensions of other applications. (So you can configure a default viewer for you database files etc. on platforms that utilize file extensions this way.) .sqlite. .sdb, .db or .db are good choices. - Danny -- Danny Reinhold Reinhold Software & Services - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] Performance benchmarking
Hi! I have recently converted a "problem application" from MS-Access to SQLite in Visual Basic but the performance is really worse then with Access. I have not changed much in the application code except for a few things that should be in favour to sqlite, like implementing a second "in memory" database for temporary data and disc based write-to db. Has anyone tested and concluded that sqlite is faster for small databases (<5000 records) so I don't sit here in vain, trying to optimize for something that just can't be done? Inserts are done in a transaction (extremely good prestanda here), selects are indexed (could this be a problem in a table with 2-3 000 records?) by adding too much overhead compared to a non-indexed, sequential, search? I haven't done any measurements, but as you already notices, SQLite needs some help to be fast. You already put your insert's in explicit transactions - good. (Hopefully you did not write begin transaction insert ... commit begin transaction insert ... commit ... but begin transaction insert ... insert ... ... commit ) You use indexes - good. But carefully check if the indexes are really used! The SQL optimizer in SQLite is pretty simple. Sometimes you can write a simple looking SQL statement that will not use indexes. So check if your indexes are being used (use the .explain command of the command line tool sqlite[.exe]). Perhaps you have to change your queries a little. For example: select * from mytable where a like 'b%'; may be slow - even if a is an indexed column. select * from mytable where a >= 'ba' and a <= 'bz'; may be very fast. Some of those tips have been discussed on this list and some tips are on the wiki. Generally you don't need to use a second in-memory db for temporary tables - SQLite will put tmp tables in memory by default... If you use indexes, write queries that force SQLite to utilize these indexes and put your inserts and updates in explicit larger transactions, SQLite should outperform nearly everything else... But I don't know the VB<->SQLite technology you use. Maybe your wrapper unneccessarily converts much data or is otherwise slow... I hope this helps a bit, Danny -- Danny Reinhold Reinhold Software & Services - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sqlite] Sqlite databases file extension
Hi, Is there a recommended file extension for sqlite database files ? If not, are there any suggestions or a commonly used extension ? What about .sqlite or .db ? Thanks, Bertrand Mansion Mamasam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] Performance benchmarking
What about transactions? Are you useing them? -- Regards Michal Zaborowski (TeXXaS) http://sqlite4delphi.sourceforge.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sqlite] Performance benchmarking
Hi, I have recently converted a "problem application" from MS-Access to SQLite in Visual Basic but the performance is really worse then with Access. I have not changed much in the application code except for a few things that should be in favour to sqlite, like implementing a second "in memory" database for temporary data and disc based write-to db. Has anyone tested and concluded that sqlite is faster for small databases (<5000 records) so I don't sit here in vain, trying to optimize for something that just can't be done? Inserts are done in a transaction (extremely good prestanda here), selects are indexed (could this be a problem in a table with 2-3 000 records?) by adding too much overhead compared to a non-indexed, sequential, search? regards /Jonas
Re: [sqlite] Journalling
Hello, v t <[EMAIL PROTECTED]> 27/10/2003 05:16 PM To: "Mrs. Brisby" <[EMAIL PROTECTED]> cc: sqlite <[EMAIL PROTECTED]> Subject:Re: [sqlite] Journalling > I am trying to use sqlite in a context where I will be using it to store some configuration about a system. I want to try to minimize the disk access. Since journalling uses a file on the disk, I wanted to turn it off. I am not worried about rolling back the database to a known state in case of some failure. You're not worried about your database becoming corrupted and all your data being destroyed? It doesn't sound like you like your data very much... ;) This is a question that pops up on the list every so often, and there have been some good reasons for it. Well. One comes to mind, and that's the use of flash memory in embedded devices. When you don't want to write to your media too many times you might find that it's better to turn off journalling and risk the consequences... perhaps make regular backups... rather than write to the media too often. The problem is that most people don't know what they're talking about when they ask how to turn journalling off. They don't understand when the journal gets written in the first place and they don't understand which operations they're performing that aren't affected by journalling. They haven't read the list archives, and they patently haven't read the manual, because it's listed under the pragma section of http://www.sqlite.org/lang.html. This is why when you ask the question on this list you get the response "Well I know you've asked how to turn off journalling, but what do you actually want to achieve by this and what alternatives have you considered?" You haven't yet given an explination that makes sense to me, so in the spirit of RTFM I'll leave you to find the exact manual reference yourself. I think it's worth you understanding, though, that journalling doesn't occur when you're only querying the database. It only happens when you modify the database. Using transactions while modifying the database is not only a good idea for data integrity, it also makes the overhead associated with synching the file to disk almost disappear so there's usually no need at all to turn off journalling. Given all of this, if you still can't find the exact spot in the manuals to turn this off yourself perhaps you could offer a more complete discussion about the nature of your database and your access to it. You'd be well advised to discuss the alternatives you have considered so that the gentle list members will feel more compelled to answer your question directly. Benjamin --Premature optimisation is the root of all evil
Re: [sqlite] Journalling
I am trying to use sqlite in a context where I will be using it to store some configuration about a system. I want to try to minimize the disk access. Since journalling uses a file on the disk, I wanted to turn it off. I am not worried about rolling back the database to a known state in case of some failure. vt "Mrs. Brisby" <[EMAIL PROTECTED]> wrote: On Thu, 2003-10-23 at 19:46, v t wrote: > Hi, > > How do I turn journalling OFF? Why do you want to? What exactly are you trying to accomplish? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Do you Yahoo!? Exclusive Video Premiere - Britney Spears
