the savings would be
> 10x
>
> Regards -- Noah
>
>
>
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Scott Hess
> Sent: Friday, April 04, 2008 9:15 AM
> To: General Discussion of SQLite Database
> Subject: Re:
On Fri, Apr 04, 2008 at 09:14:52AM -0700, Scott Hess scratched on the wall:
> What I meant when I said "full table scan" is that it has to read at
> least something for every single row in the table. So the following
> are going to be the same:
>
> SELECT COUNT(*) FROM t;
> SELECT
, April 04, 2008 9:15 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] Count(1)
What I meant when I said "full table scan" is that it has to read at
least something for every single row in the table. So the following
are going to be the same:
SELECT COUNT(*) FROM t
What I meant when I said "full table scan" is that it has to read at
least something for every single row in the table. So the following
are going to be the same:
SELECT COUNT(*) FROM t;
SELECT COUNT(rowid) FROM t;
It won't have to scan any overflow pages, but it will have to hit all
the
On Fri, Apr 04, 2008 at 11:19:53AM -0400, Samuel Neff wrote:
> Is it really a full table scan or just an index scan (at least in the case
> where no data is needed from the table as in the original sample that had no
> join or where clause).
Either way it's O(N) instead of O(1), which is what the
On Fri, Apr 04, 2008 at 11:19:53AM -0400, Samuel Neff scratched on the wall:
> Scott,
>
> Is it really a full table scan or just an index scan (at least in the case
> where no data is needed from the table as in the original sample that had no
> join or where clause).
I wondered about this
Scott,
Is it really a full table scan or just an index scan (at least in the case
where no data is needed from the table as in the original sample that had no
join or where clause).
Thanks,
Sam
On Thu, Apr 3, 2008 at 4:12 PM, Scott Hess <[EMAIL PROTECTED]> wrote:
> A little bit more info:
A little bit more info: SELECT COUNT(*) is implemented as a full
table scan, so SQLite is visiting every row in the table, which will
get slower and slower as the table gets bigger and the database
fragments. This differs from many database engines (which implement
an optimization for this)
You could use a trigger to keep the running total in a seperate table.
"Mahalakshmi.m" <[EMAIL PROTECTED]> wrote: Hi,
I am having 4 records in my Harddisk.
My Processor speed is 400 Mhz.
For "SELECT COUNT(1) FROM MUSIC ;" its getting more time to display the
count.
I have also tried with
On 4/3/08, Mahalakshmi.m <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I am having 4 records in my Harddisk.
> My Processor speed is 400 Mhz.
>
> For "SELECT COUNT(1) FROM MUSIC ;" its getting more time to display the
> count.
> I have also tried with "SELECT COUNT(*) FROM MUSIC ;This also take
Hi,
I am having 4 records in my Harddisk.
My Processor speed is 400 Mhz.
For "SELECT COUNT(1) FROM MUSIC ;" its getting more time to display the
count.
I have also tried with "SELECT COUNT(*) FROM MUSIC ;This also take more
time.
Is there any other way we can get the Total number of records.
11 matches
Mail list logo
