Very large indices could well be a problem when mmap'd, but in our case
we used one file per index and the problem did not occur, even in the
largest datasets.
The OS's used were Solaris, AIX, Linux and Windows on big anf little end
machines. Not HPUX fortunately :-).
As you correctly
On Wed, 22 Mar 2006, John Stanton wrote:
>Our approach to byte order independence was fairly simple, and worked
>well with a mmap'd index. It involved keeping the just word pointers in
>a local byte ordered block if the machine were a different Endian. The
>overhead was next to insignificant.
Thursday, March 23, 2006, 03:44:11, Teg wrote:
> Hello Jay,
> Best way I've found to get great performance out of strings and
> vectors is to re-use the strings and vectors. String creation speed is
> completely dependent on allocation speed so, by re-using the strings,
> you only grow the ones
Back in my past I used Oracle OCI and did "array" inserts where you
would load an array for
each column to be inserted. bind the arrays to the insert statement and
then do a big insert.
It was a quite fast way to load data.
Joe Wilson wrote:
Some people on the list have noted that inserting
On 3/22/06, Teg <[EMAIL PROTECTED]> wrote:
> Hello Jay,
>
> Best way I've found to get great performance out of strings and
> vectors is to re-use the strings and vectors. String creation speed is
> completely dependent on allocation speed so, by re-using the strings,
> you only grow the ones that
Hello Jay,
Best way I've found to get great performance out of strings and
vectors is to re-use the strings and vectors. String creation speed is
completely dependent on allocation speed so, by re-using the strings,
you only grow the ones that aren't already big enough to hold the new
string data
On 3/22/06, Micha Bieber <[EMAIL PROTECTED]> wrote:
> Eventually, I've got my lesson. Because it might be of some interest for
> the beginner:
>
> 1)Use the associated sqlite3_bind_* variants for your data.
> I did make a mistake in converting forth and back to strings beforehand.
>
> 2)It broke
Eventually, I've got my lesson. Because it might be of some interest for
the beginner:
1)Use the associated sqlite3_bind_* variants for your data.
I did make a mistake in converting forth and back to strings beforehand.
2)It broke my program design a bit, but setting up large STL vector
based
Our approach to byte order independence was fairly simple, and worked
well with a mmap'd index. It involved keeping the just word pointers in
a local byte ordered block if the machine were a different Endian. The
overhead was next to insignificant. Our indices were all byte order
On Wed, Mar 22, 2006 at 10:41:23AM +1100, John Stanton wrote:
> The mmap'd index was about three times faster than when it
> used a LRU paged cache.
I looked fairly closely into the possibility of using mmap for the
SQLite btree backend, and realized that it would be quite difficult.
Because
Some people on the list have noted that inserting pre-sorted
rows in sub-batches into SQLite is faster than inserting
unsorted rows. Granted, you could only do this for one index
per table, but might this be the basis of an optimization?
(I have not looked at the insert code. Perhaps SQLite is
Micha Bieber <[EMAIL PROTECTED]> wrote:
> Appending all 25*10^6 rows takes 40
> minutes on a PC with 3 GHz, 1GB memory and sufficient large harddisk.
>
Inserting 25-million rows in a table should be quick.
Building an index (or indices) on a 25-million row table
takes much longer.
You did not
Hallo list,
I'm relatively inexperienced when it comes to databases and SQL (but to
programming). I'm using sqlite's (recent version) C API called from a
C++ application.
I'm confronted with the following situation:
Ca. 2500-3000 objects (called 'entity') everyone with 3 properties (REAL
in
13 matches
Mail list logo
