Hi,
What factor of speed improvement could I expect with a memory database?
The database is located on compact flash(vfat) and has a size of 1 MB.
Thank you very much
Roger Meier
The use of sequential numbers as the trailing part of the 'word'
results in a continual rebalancing of the b-tree with each insertion.
Is that right considering it looks like you have not created an index on
the word column before inserting the data?
Nick
On Mon, 26 Jun 2006 11:20:59 +0100, Brandon, Nicholas (UK) wrote:
The use of sequential numbers as the trailing part of the 'word'
results in a continual rebalancing of the b-tree with each insertion.
Is that right considering it looks like you have not created an index on
the word column
Garrett Rooney [EMAIL PROTECTED] wrote:
Your grammer does not generate an empty string. That means
if you call the parser with an EOF token first, without any
prior tokens, you are going to get a syntax error. The
yymajor==0 test was removed in order to get this to
work correctly.
The .h file is in the preprocessed source. The def file lists the
exports from the dll, which is useful when some new experimental
functions get defined in the .h file, but are not yet exported form
the Dll.
On 25/06/06, onemind [EMAIL PROTECTED] wrote:
Hi,
I am trying to use the .dll with c
--- John Stanton [EMAIL PROTECTED] wrote:
Meier, Roger wrote:
Hi,
What factor of speed improvement could I expect
with a memory database?
Little to none
This is my experience as well, under a variety of
conditions that I have tested. It is interesting; at
times, it may in fact be
On 6/26/06, C.Peachment [EMAIL PROTECTED] wrote:
The use of sequential numbers as the trailing part of the 'word'
results in a continual rebalancing of the b-tree with each insertion.
Is that right considering it looks like you have not created an index on
the word column before inserting the
Hi,
How to make a case insensitieve index ?
I tryed with [lower(fieldname)] and other combinations but this give me a
syntax error.
The select will work with 'order by lower(fieldname)' but it should use the
right index.
--
View this message in context:
Joe Wilson wrote:
I think some other factor is at play here.
SQLite 2.x's memory databases are still twice as fast at batch inserts
than either 3.x's disk-based databases or 2.x's disk-based databases
when the DB size is less than physical machine memory.
Joe,
Yes there is another
Hi,
Made an extra field with a lowercase portion of the field I wants to sort
on. I think it is the most fast. Of course when someone can give better
advice it is very welcome :)
rgds, Wilfried
--
View this message in context:
* Wilfried Mestdagh [EMAIL PROTECTED] [2006-06-26 15:45]:
How to make a case insensitieve index ?
Add `COLLATE NOCASE` to the column definition.
See http://www.sqlite.org/datatype3.html
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
Dennis Cote wrote:
Joe Wilson wrote:
I think some other factor is at play here.
Yes there is another factor at work here. [...] I suspect there are
optimizations that could be made to the memory I/O routines to speed
them up, they should at least be able to run slightly faster than file
Fred Williams wrote:
If brackets are a visual distraction, more common Quote Marks may be
used as well.
Not only are double quote characters more common, they are the standard
method for quoting names in SQL. The square brackets are a non-standard
extension introduced by Microsoft in
Thank you for the advice and the url :)
--
View this message in context:
http://www.nabble.com/how-make-a-case-insensitive-index-t1849023.html#a5049996
Sent from the SQLite forum at Nabble.com.
I'll confess that I am an old-fashioned hardcopy kind of guy... are the
sqlite3 docs available in any sort of reasonably-printable format?
/Bernie\
--
Bernie Cosell Fantasy Farm Fibers
mailto:[EMAIL PROTECTED] Pearisburg, VA
-- Too many people, too few sheep --
Just wanted to warn you i can not read a newly created table created with
the current release and opening it in v3.2.1 (afaik)
Sorry, i removed the older dll, i overwrote it with the latest and read the
table instantly.
Before i had 0 tables shown.
A simple query was used:
CREATE TABLE
Bernie Cosell [EMAIL PROTECTED] wrote:
I'll confess that I am an old-fashioned hardcopy kind of guy... are the
sqlite3 docs available in any sort of reasonably-printable format?
http://www.apress.com/book/bookDisplay.html?bID=10130
--
D. Richard Hipp [EMAIL PROTECTED]
On Mon, 26 Jun 2006 20:03:35 +0200, Edwin Knoppert wrote:
Just wanted to warn you i can not read a newly created table created with
the current release and opening it in v3.2.1 (afaik)
Sorry, i removed the older dll, i overwrote it with the latest and read the
table instantly.
Before i had 0
Edwin Knoppert [EMAIL PROTECTED] wrote:
Just wanted to warn you i can not read a newly created table created with
the current release and opening it in v3.2.1 (afaik)
Sorry, i removed the older dll, i overwrote it with the latest and read the
table instantly.
Before i had 0 tables shown.
OK, thanks!
Must been a change in the fileformat then..
A bit odd the system does not handle backwards compatibility in minor
releases.
:)
PS, still can't find my own post, while a reply is given.. odd
- Original Message -
From: C.Peachment [EMAIL PROTECTED]
To:
You can create the database with the older Sqlite version, but any use
with the new version must be preceded by the pragma, otherwise the
new version changes the data format, making it unreadable by the
old version thereafter.
It got me confused when I started too.
On Mon, 26 Jun 2006 21:28:59
At 2:20 PM -0400 6/26/06, [EMAIL PROTECTED] wrote:
SQLite 3.3.0 can read and write all prior versions of SQLite
databases. But SQLite 3.2.8 cannot read or write a database
created by SQLite 3.3.0, unless you use
PRAGMA legacy_file_format=TRUE;
prior to creating the database, or unless you
C.Peachment [EMAIL PROTECTED] wrote:
You can create the database with the older Sqlite version, but any use
with the new version must be preceded by the pragma, otherwise the
new version changes the data format, making it unreadable by the
old version thereafter.
The file format is only
Peter Bierman [EMAIL PROTECTED] wrote:
At 2:20 PM -0400 6/26/06, [EMAIL PROTECTED] wrote:
SQLite 3.3.0 can read and write all prior versions of SQLite
databases. But SQLite 3.2.8 cannot read or write a database
created by SQLite 3.3.0, unless you use
PRAGMA legacy_file_format=TRUE;
Thanks, but do not base your decision on my.
I'm using sqlite to little to complain, i simply was not aware of the
change.
I write software to make use of sqlite for other people (a designer).
I only need to mention this issue.
- Original Message -
From: [EMAIL PROTECTED]
To:
DJ Anubis wrote:
Robert L Cochran a écrit :
However, on Fedora Core 5, my path is set so that objects on
/usr/local/bin are found before those on /usr/bin. I'm not sure how this
is happening; perhaps /etc/profile? The result seems to be that even if
sqlite 3.3.3 was installed by yum,
Hi,
I am really really thankful to all the members of this group. The Discussion
here was really very helpful for me and also for the others.
I was not as much experienced as the other members who took part in this
dicussion, but i worked hard ad spent a lot of time to find out why i am
--- Martin Jenkins [EMAIL PROTECTED] wrote:
For :memory: databases, long periods
were observed where the VM size crept up but I/O write bytes did not,
followed by periods where I/O bytes increased.
If you use PRAGMA temp_store=MEMORY with your :memory: database
you will have no I/O
I think some other factor is at play here.
SQLite 2.x's memory databases are still twice as fast at batch inserts
than either 3.x's disk-based databases or 2.x's disk-based databases
when the DB size is less than physical machine memory.
I did some experimentation with an SQLite 2.8.17
--- Meier, Roger [EMAIL PROTECTED] wrote:
Hi,
What factor of speed improvement could I expect with a memory database?
The database is located on compact flash(vfat) and has a size of 1 MB.
Thank you very much
Roger Meier
It depends what you mean by 'memory database' and the hardware
On 26 Jun 2006 at 14:14, [EMAIL PROTECTED] wrote:
Bernie Cosell [EMAIL PROTECTED] wrote:
I'll confess that I am an old-fashioned hardcopy kind of guy... are the
sqlite3 docs available in any sort of reasonably-printable format?
http://www.apress.com/book/bookDisplay.html?bID=10130
It also depends on the synchronous pragma. If you leave synchronous on with
a disk DB, you will see a huge improvement with an in-memory. With
synchronous off, there is not that big an improvement until you start
inserting large amounts of data. You will then start seeing a slight
improvement.
Do you know exactly which version of SQLite the book discusses?
Version 3.3.x.
The examples all use 3.3.4. For what it is worth, my review of the
book is at:
http://www.rogerbinns.com/sqlitereview.html
Roger
i am looking for a embeddable sql database that i can use to manipulate
memory stored in battery back sram. would sqllite be cable of doing this?
thanks
j osburn
Joe Wilson wrote:
--- Martin Jenkins [EMAIL PROTECTED] wrote:
For :memory: databases, long periods
were observed where the VM size crept up but I/O write bytes did not,
followed by periods where I/O bytes increased.
If you use PRAGMA temp_store=MEMORY with your :memory: database
you will
35 matches
Mail list logo
