On 6/22/10, Eric Smith wrote:
> Jim Wilcoxson wrote:
...
>> Did you see my earlier note about combining your two integers into the
>> primary key? This will also give you constant insert times, if you
>> insert items in the order:
...
> Thanks also for the tip on insertion order. Does that also
On 23 Jun 2010, at 1:18am, Eric Smith wrote:
> *sigh* kill me. Sorry for wasting your time there. :/
We've all done it.
Simon.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Scott Hess wrote:
> You should reduce your demonstration case to something you'd be
> willing to post the code for. Probably using synthetic data
> (preferably generated data). There's something missing in the thread
> right now, and it's unlikely to be exposed by random shots in the
> dark
Scott Hess wrote:
> You should reduce your demonstration case to something you'd be
> willing to post the code for. Probably using synthetic data
> (preferably generated data). There's something missing in the thread
> right now, and it's unlikely to be exposed by random shots in the
> dark
Eric,
You should reduce your demonstration case to something you'd be
willing to post the code for. Probably using synthetic data
(preferably generated data). There's something missing in the thread
right now, and it's unlikely to be exposed by random shots in the
dark.
-scott
On Tue, Jun 22,
Jay A. Kreibich wrote:
> What OS/filesystem are you using?
>
> SQL inserts should be near-constant, assuming the table does not
> have an INTEGER PRIMARY KEY with explicit values. The table's root
> B-Tree needs to re-balance every now and then, but if the inserts are
> in-order (which th
Uggg
On Tue, Jun 22, 2010 at 05:12:38PM -0500, Jay A. Kreibich scratched on the wall:
> On Tue, Jun 22, 2010 at 04:16:42PM -0400, Eric Smith scratched on the wall:
> > Jim Wilcoxson wrote:
> >
> > > Insert times should be constant for the 2nd case: no primary key, no
> > > indexes; ie,
On Tue, Jun 22, 2010 at 04:16:42PM -0400, Eric Smith scratched on the wall:
> Jim Wilcoxson wrote:
>
> > Insert times should be constant for the 2nd case: no primary key, no
> > indexes; ie, it doesn't matter how many records are already in the
> > database. I confirmed this with SQLite 3.6.18
Richard Hipp wrote:
> When there are no indices, SQLite can put the rows into the database in
> any order it wants, and it chooses to put them in ascending order. Thus,
> each insert becomes a constant-time append. (Approximately - the truth is
> a little more complicated, but by waving our
On Tue, Jun 22, 2010 at 3:08 PM, Eric Smith wrote:
> I have confirmed that INSERT times are roughly logarithmic in
> the number of existing records after creating my specific user
> indices.
>
> But INSERT times appeared to be *linear* in the number of existing
> records before I had created any
Jim Wilcoxson wrote:
> Insert times should be constant for the 2nd case: no primary key, no
> indexes; ie, it doesn't matter how many records are already in the
> database. I confirmed this with SQLite 3.6.18.
Definitely not constant. Looks linear to me -- you saw the plot, you
can decide
On 6/22/10, Eric Smith wrote:
> I have confirmed that INSERT times are roughly logarithmic in
> the number of existing records after creating my specific user
> indices.
>
> But INSERT times appeared to be *linear* in the number of existing
> records before I had created any user indices (and with
I have confirmed that INSERT times are roughly logarithmic in
the number of existing records after creating my specific user
indices.
But INSERT times appeared to be *linear* in the number of existing
records before I had created any user indices (and with no primary
keys or unique indices def
13 matches
Mail list logo