Hi,
> And will only work if you never delete any rows from the table.
Yes, I am aware of that limitation and I am not ever deleting apart from
a full truncate. I have yet to test that case, if shut turn out to not
work I can live with a DROP TABLE or even delete the database file. It
is
> > select max(rowid) from sometable;
>
> Looks good and is instantaneous. Thank you very much.
And will only work if you never delete any rows from the table.
___
sqlite-users mailing list
sqlite-users@sqlite.org
Hi,
> select max(rowid) from sometable;
Looks good and is instantaneous. Thank you very much.
Ciao, MM
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
"Marian Aldenhoevel"
<[EMAIL PROTECTED]> wrote in
message news:[EMAIL PROTECTED]
> SELECT COUNT(*) FROM sometable;
>
> Takes 10 seconds on my testcase (340.000 rows, Database on CF, dead
> slow CPU).
>
> Is there a quicker way? Does SQLLite maybe store the total number of
> records somewhere else?
Hi,
> Depending on your setup and depending on how often you need to query the
> count you could trade off a higher INSERT time for a lightning fast
> count by using a trigger.
I have thought about that as well, yes. I have bulk-Inserts that
prepropulate the table with a starting set of about
Marian Aldenhoevel wrote:
> Hi,
>
> SELECT COUNT(*) FROM sometable;
>
> Takes 10 seconds on my testcase (340.000 rows, Database on CF, dead slow
> CPU).
>
> Is there a quicker way? Does SQLLite maybe store the total number of
> records somewhere else?
>
> The table only ever grows, there are now
Hi,
SELECT COUNT(*) FROM sometable;
Takes 10 seconds on my testcase (340.000 rows, Database on CF, dead slow
CPU).
Is there a quicker way? Does SQLLite maybe store the total number of
records somewhere else?
The table only ever grows, there are now DELETEs on it ever, apart from
complete
7 matches
Mail list logo
