Hi,
> > It might make sense to create a separate standalone utility program
> > (like sqlite3_analyzer) that reuses some the sqlite source
> to do bulk
> > inserts into a table in a database file as fast a possible with out
> > having to worry about locking or journaling etc.
>
> That
John,
Thanks for the useful info. Unfortunately it sounds as if this is more
than I have time for right now.
Stephen
On Wed, 2007-03-28 at 16:29 -0600, John Stanton wrote:
> Perl would not do a good job. You need to use the Sqlite page
> structures and they are defined in C terms.
>
> If
John Stanton wrote:
Perl would not do a good job. You need to use the Sqlite page
structures and they are defined in C terms.
But Tcl might. The test suite pokes about with SQLite internals.
Martin
-
To unsubscribe,
Perl would not do a good job. You need to use the Sqlite page
structures and they are defined in C terms.
If you want to make such a program I can give you a template in simple
ANSI C. It builds to a different data structure from Sqlite but the
algorithms are there. It uses a quicksort as
I may work on such a program, if time permits. If successful I will
share it. It would be in Perl using DBI::ODBC, so may not be amazingly
fast.
I am pretty good at C++ but have phased it out for most work, so I am
still using the antique Sybase compiler, and I doubt the SQLite C++
library would
RB Smissaert wrote:
Just one question; as I log nearly all my SQL statements to
a SQLite table, will this be OK with the double quotes added?
If I understand your question correctly the answer is of course, you are
simply logging the text of the SQL as a literal string.
The literal string
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Difference in these indices?
RB Smissaert wrote:
> Does this only apply to table and column names?
> I will never use double quote characters in my identifier
> names, so there should be no problem there.
>
>
It applies to all the ide
RB Smissaert wrote:
Does this only apply to table and column names?
I will never use double quote characters in my identifier
names, so there should be no problem there.
It applies to all the identifiers: table, column, index, trigger,
database (using attach as id), transactions (if named
Joe,
In general the storage concept would be nice to extend this to a more general
case.
Extend the sql language to allow storage to a specified file. This would
allow the user to easily seperate the data vs indices.
ie Create table ... ( column ) storage-clause
: 28 March 2007 15:41
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Difference in these indices?
RB Smissaert wrote:
> As to quotes etc.
> As my code works fine as it is I probably will leave this as the double
> quotes look ugly and it will be a reasonably big job to alter all this.
&g
RB Smissaert wrote:
As to quotes etc.
As my code works fine as it is I probably will leave this as the double
quotes look ugly and it will be a reasonably big job to alter all this.
Did I get you right that the only benefit of doing create "table1" etc.
is compatibility with running sqlite with
Joe Wilson wrote:
SQLite is extremely fast in most area of SQL functionality except for
bulk inserts of non-ordered data into multi-indexes tables, where it
is very slow.
Are you sure that it's really "very slow" compared to other database
engines? How does its insert speed compare to
On 3/28/07, Joe Wilson <[EMAIL PROTECTED]> wrote:
I believe 2 measures when applied together would significantly
improve insert speed of indexed rows:
1. Allot each index/btree a contiguous region of the database file in
which to grow without conflicting with the other indexes' pages and pages
--- [EMAIL PROTECTED] wrote:
> If you insert records in order of ascending integer primary
> key, then the inserts will be very fast. If you insert records
> where the integer primary key is randomized, inserts will be
> reasonably fast until the size of your table exceeds the size
> of your disk
this.
Did I get you right that the only benefit of doing create "table1" etc.
is compatibility with running sqlite with SQLite.exe?
RBS
-Original Message-
From: Dennis Cote [mailto:[EMAIL PROTECTED]
Sent: 27 March 2007 23:41
To: sqlite-users@sqlite.org
Subject: Re: [sqlite]
]
Sent: 27 March 2007 23:34
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Difference in these indices?
"RB Smissaert" <[EMAIL PROTECTED]> wrote:
> Thanks for that.
> So if I can then I should create the table with INTEGER PRIMARY KEY.
> Is it right that this won'
RB Smissaert wrote:
Is it right that this won't affect the speed of any subsequent inserts or
deletes?
Well inserts will be done in id order. If you have predefined ids
assigned by some outside source and specify them when you insert into
sqlite, it will have to insert at random location in
"RB Smissaert" <[EMAIL PROTECTED]> wrote:
> Thanks for that.
> So if I can then I should create the table with INTEGER PRIMARY KEY.
> Is it right that this won't affect the speed of any subsequent inserts or
> deletes?
>
That depends on the data.
If you insert records in order of ascending
PRIMARY KEY)"
RBS
-Original Message-
From: Dennis Cote [mailto:[EMAIL PROTECTED]
Sent: 27 March 2007 22:51
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Difference in these indices?
RB Smissaert wrote:
> Is there any difference in an index created like this:
>
> Create
RB Smissaert wrote:
Is there any difference in an index created like this:
Create table 'table1'([ID] INTEGER PRIMARY KEY)
with this:
Create table 'table1'([ID] INTEGER)
Create unique index idx_table1_ID on table1(ID)
I tended to use the first form, but as that can make subsequent table
20 matches
Mail list logo
