mmm... I didnt state a problem, I stated a question: How much time will it take to reindex the new timestamp? As you can see, i do only update to the row. The things that changed are the data and the time stamp. Because the time stamp is PK i guess it will have to reindex the table, no? How bad in performance is it?
Black, Michael (IS) wrote: > > What you're saying makes sense. But you haven't stated a problem... > > > > Are you far enough along you can show timing beween 1st and 2nd queue > fills? > > > > How long does it take you to insert your first million? > > How long does it take you to insert your second million? > > > > > > Michael D. Black > > Senior Scientist > > NG Information Systems > > Advanced Analytics Directorate > > > > ________________________________ > From: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] on > behalf of LiranR [liran.rit...@gmail.com] > Sent: Wednesday, August 24, 2011 6:39 AM > To: sqlite-users@sqlite.org > Subject: EXT :Re: [sqlite] Re indexing (if such a thing exist) performance > > > I use: > > ID (PK) | TimeStamp (PK) | data | data | and data ... > ------------------------------------------------------------- > 1 | 1000001 | float | float | float > 2 | 1000002 | float | float | float > 3 | 3 | float | float | float > 4 | 4 | float | float | float > ... | ... | float | float | float > > As you can see, the table is already has been filled, and its the second > time entering data. > the next row to update is row 3, which will be have TimeStamp 1000003. > Because the face that time stamp is always rising, i can't leave there > only > the number 3. Also, I have to use TimeStamp as PK (Primary Key) because of > the fact that when i want to read data from the table i search the table > by > timestamp. > > > Kees Nuyt wrote: >> >> On Wed, 24 Aug 2011 02:58:58 -0700 (PDT), LiranR >> <liran.rit...@gmail.com> wrote: >> >>> >>> Hi, Thanks for the answer, but i think you didn't understand what i >>> asked. >>> >>> I use primary key index in my table. >>> When i finish to fill the table, row after row, i want to start all over >>> again and update the table from row 1 to row 1000000. The difference is >>> that >>> in the second time, the index of the first row wont be 1, but 1000001, >>> and >>> then i will update the second row and it's index will be 1000002, and so >>> on... (when i reach the 1000000 row, i update it with the index 2000000, >>> and >>> than again, first row will be update with index 2000001). >>> My question is - Does it take heavy performance to reindex the row every >>> time (because the row get another index number - in this example, a >>> number >>> that is bigger by 1000000 than the last row's index number). >> >> It will take about the same effort as deleting and inserting a >> row, or about twice as much as inserting a row. >> Show us your schema and we may be able to advise on optimizations. >> (output of .schema in the sqlite3 command line tool will do). >> >> Note: index is a resserved word. Using it as a column name is >> confusing. >> -- >> ( Kees Nuyt >> ) >> c[_] >> _______________________________________________ >> sqlite-users mailing list >> sqlite-users@sqlite.org >> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users >> >> > > -- > View this message in context: > http://old.nabble.com/Reindexing-%28if-such-a-thing-exist%29-performance-tp32324832p32325716.html > Sent from the SQLite mailing list archive at Nabble.com. > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > -- View this message in context: http://old.nabble.com/Reindexing-%28if-such-a-thing-exist%29-performance-tp32324832p32325797.html Sent from the SQLite mailing list archive at Nabble.com. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users