You can make the timestamps unique by appending a sequence number. A 32
bit Unix timestamp can map into a 64 bit Sqlite integer.
P Kishor wrote:
> On 4/14/08, Chris Tracy <[EMAIL PROTECTED]> wrote:
>> Err,
>>
>> Make that example table data:
>>
>> <...>
>>
>> 1167611400|89|7|34
>>
for early times.
RBS
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: 14 April 2008 19:11
To: General Discussion of SQLite Database
Subject: Re: [sqlite] Implicit INDEX?
How about this:
select
*
from
table1
where
rowid >=
(select
ro
Does sqlite have support for index based tables as a storage means?
This is an excelent case for index based storage.
just my .02
Ken
Dennis Cote <[EMAIL PROTECTED]> wrote: Jeffrey Rennie wrote:
> On Mon, Apr 14, 2008 at 9:48 AM, Chris Tracy wrote:
>
inserted into the database in
On 4/14/08, Dennis Cote <[EMAIL PROTECTED]> wrote:
> Jeffrey Rennie wrote:
> > On Mon, Apr 14, 2008 at 9:48 AM, Chris Tracy <[EMAIL PROTECTED]> wrote:
> >
> inserted into the database in ascending order, and where there may be
> >> as
> many as 500 hID entries for each timestamp.
Jeffrey Rennie wrote:
> On Mon, Apr 14, 2008 at 9:48 AM, Chris Tracy <[EMAIL PROTECTED]> wrote:
>
inserted into the database in ascending order, and where there may be
>> as
many as 500 hID entries for each timestamp. After a while, this table
>>> Have you considered making timestamp
On Mon, Apr 14, 2008 at 9:48 AM, Chris Tracy <[EMAIL PROTECTED]> wrote:
> >> inserted into the database in ascending order, and where there may be
> as
> >> many as 500 hID entries for each timestamp. After a while, this table
>
> > Have you considered making timestamp a PRIMARY KEY?
> >
> >
On 4/14/08, Chris Tracy <[EMAIL PROTECTED]> wrote:
> > If you need to do this from the shell, I'm not sure there is anything
> > you can do. If you're doing this from the C API just look for timestamps
> > that are >= your target and terminate the query as soon as you find one
> > larger
On Mon, 4/14/08, Chris Tracy <[EMAIL PROTECTED]> wrote:
> From: Chris Tracy <[EMAIL PROTECTED]>
> Subject: Re: [sqlite] Implicit INDEX?
> To: "General Discussion of SQLite Database" <sqlite-users@sqlite.org>
> Date: Monday, April 14, 2008, 1:35 PM
&
Donald,
> To test this, I think you'd want to create a select for some of the most
> recent data (i.e. data at the tail of the database), perhaps after
> clearing cache. I suspect this will take the full table scan time to
> return any values.
I'd actually just thought of that. All my
> If you need to do this from the shell, I'm not sure there is anything
> you can do. If you're doing this from the C API just look for timestamps
> that are >= your target and terminate the query as soon as you find one
> larger than the target timestamp (e.g. stop calling step() and call
>
On Mon, Apr 14, 2008 at 10:06:27AM -0700, Chris Tracy scratched on the wall:
> > Your first sentence above is that you "almost immediately get back all
> > the results you want" then you go on to say that the "actual SELECT
> > doesn't return for almost 13 additional seconds." So, what is it
> >
Hi, Chris,
Regarding: "It seems to me (and I might be wrong) that since the values
are already in the database in ascending order by timestamp that SQLite
is able to find all the results quite quickly. ..."
To test this, I think you'd want to create a select for some of the most
recent data
> a shot in the dark. Try
>
> SELECT * from bridge_table WHERE timestamp < 1167615601;
>
> although, it would probably not help because SQLite would still have
> to scan the table to ascertain there were no more rows that met the
> criterion. My hunch is that without giving the program some hint
On 4/14/08, Chris Tracy <[EMAIL PROTECTED]> wrote:
> > Your first sentence above is that you "almost immediately get back all
> > the results you want" then you go on to say that the "actual SELECT
> > doesn't return for almost 13 additional seconds." So, what is it
> > exactly that you "almost
> Your first sentence above is that you "almost immediately get back all
> the results you want" then you go on to say that the "actual SELECT
> doesn't return for almost 13 additional seconds." So, what is it
> exactly that you "almost immediately get back"?
When I run the select inside
On 4/14/08, Chris Tracy <[EMAIL PROTECTED]> wrote:
> Err,
>
> Make that example table data:
>
> <...>
>
> 1167611400|89|7|34
> 1167611400|101|5|4
> 1167611400|147|9|14
> 1167611400|173|7|2
> 1167611400|195|8|1
> 1167611400|314|8|12
> 1167611400|347|6|48
> 1167611400|364|1|49
>
>
>
Err,
Make that example table data:
<...>
1167611400|89|7|34
1167611400|101|5|4
1167611400|147|9|14
1167611400|173|7|2
1167611400|195|8|1
1167611400|314|8|12
1167611400|347|6|48
1167611400|364|1|49
1167615600|111|7|39
1167615600|155|2|8
1167615600|157|4|7
1167615600|220|4|47
>> inserted into the database in ascending order, and where there may be as
>> many as 500 hID entries for each timestamp. After a while, this table
> Have you considered making timestamp a PRIMARY KEY?
>
> So, declare it as INTEGER PRIMARY KEY NOT NULL
Unfortunately, the timestamps
On 4/14/08, Chris Tracy <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I'm a relative newcommer to SQL and SQLite and have was is likely
> a silly question. However, I've not found an answer to it or even a
> reference to anything similar in searching the list archives or the web.
>
>
Hello,
I'm a relative newcommer to SQL and SQLite and have was is likely
a silly question. However, I've not found an answer to it or even a
reference to anything similar in searching the list archives or the web.
If I have a table laid out thusly:
CREATE TABLE bridge_table (
20 matches
Mail list logo
