Re: [sqlite] Feature Request - RowCount

[Paul]

> 
> On 14 Dec 2014, at 11:08am, Jean-Christophe Deschamps  
> wrote:
> 
> > Without using slow triggers or changing the v3 file format there is still 
> > another possibility which could be implemented relatively easily. All it 
> > would need is a new pragma (or internal function) like "pragma 
> > row_count=0/1" and some code.
> > 
> > On invokation, the engine would create a hidden "system" table like 
> > sqlite_rowcount --similar to sqlite_sequence-- which would initially hold 
> > row counts for every table in the DB.
> 
> Two obvious places:
> 
> A) In that sqlite_sequence table you mentioned, as an additional column. 
> Always up-to-date.
> 
> B) In the tables prepared by SQLite ANALYZE. If you want the rowcount 
> updated, do another ANALYZE.

It's just my two cents, but if you take time to run ANALYZE and you 
don't care for the value to be synced with the real row count 
in between two ANALYZEs, why not make a table for your convenience,
that will do the same thing you want ANALYZE to do. IE you make 
a script that will select all names of the tables in database:

  SELECT name FROM sqlite_master WHERE type = 'table' AND name NOT LIKE 
'sqlite_%';

And then will perform 

  INSERT INTO my_row_count_cache(table_name, row_count)
  SELECT 'XXX' AS name, (SELECT COUNT(*) FROM XXX) AS count;

for each resulting table.

All this can actually be implemented as an SQLite add-on, via virtual table.
So for example, instead of doing

  SELECT COUNT(*) FROM XXX;

you could do

  SELECT count FROM vtb_row_count_cache WHERE table = 'XXX';


Just and idea...

Regards,
Paul
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Feature Request - RowCount

[RSmith]

On 2014/12/13 21:46, James K. Lowden wrote:

So the number of tools with feature X is no measure of the value of X. (Notable example: the tool should keep every query and 
result in a time-sequenced transcript log, so that prior results can be re-examined and prior queries modified. Most tools 
disassociate query from output and invite the user to modify the query in-place, destroying the prior.) 


This is hardly a function of the DB admin tools though, it's a research function or application function (depending on whether the 
inquest is theoretical or physical). That said, many of the tools I know do allow saving queries as scripts with the possibility to 
examine output at every step, but not all of them, so this might be somewhat valid.  More importantly, I was not touting the idea 
that because all the tools use feature X, it is therefore valid... I more conceded the fact that the request for feature X is 
valuable (mostly) only to those tools, which probably renders it less urgent - quite in agreement with your point.


My first question, then, is whether or not the rowcount is so interesting that it must be known before a table can be operated on. 
I suggest the answer is No. The relative & approximate sizes of the tables is known to the admin in most cases and, when it is 
not, the information is readily discovered on a case-by-case basis. Would a proxy figure do? Is it enough to know the number of 
pages or bytes allocated to a table? I don't know if such is available, but if it is perhaps that would serve your purpose. 


Yes, this would actually do, but it is not available as you rightly pondered. To the point of necessity, I have to disagree.  It is 
nearly always the first thing I want to know. When someone here is troubled by a query running time... first question is: how many 
rows are in which joined tables? To state the problem a bit simplistic - It is hard to fathom the meaning of O log N without a clear 
understanding of what both O and N might be.  And that's just from a DB admin perspective, in companies where the business analysis 
data matter, lots of queries are usually stored as tables for further analysis, and the first thing asked is: How many?  Other times 
that figure serves probably only as bemusement to big data fans.  It's usually (I'd say vast majority of cases) an easy and fast 
step to ascertain though (as this discussion pointed out) hence me resting the case - but I do stand by the point that the need 
isn't invalid.


___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Feature Request - RowCount

[Klaas V]

Jim Callahan wrote:>#26 The unique columns have non-null values (the answer 
says a lot more,>but that is the essence of what I am relying on).
Right, but the question was how to count rows as quickly as possible regarding 
any or all columnse.g. count(ProspectName) from Clients; 
One can imagine from some prospects you don't know the (real) name yet, just 
her or his emailAddress
>#1 If you have an integer primary key (which by definition in 
>SQLITE3>autoincrements) one might be able to get an approximate row count 
>faster>using the:
>sqlite3_last_insert_rowid() function.
If you're happy with an approximate count, but as soon as rows are deleted the 
last inserted row# may and will be more off an accurate value. Far off at some 
point in time that it becomes unacceptable for most managers.

>Jim Callahan>Orlando, FL
 
Kind regards | Cordiali saluti | Vriendelijke groeten | Freundliche Grüsse,
Klaas `Z4us` V  - OrcID -0001-7190-2544
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Feature Request - RowCount

[Jean-Christophe Deschamps]

Hi Simon,

A) In that sqlite_sequence table you mentioned, as an additional 
column.  Always up-to-date.


But sqlite_sequence isn't always created. AFAIK it only exists when one 
or more table exists with an integer primary key autoincrement.


B) In the tables prepared by SQLite ANALYZE.  If you want the rowcount 
updated, do another ANALYZE.


But then the row count isn't always up-to-date and this would be 
essentially no different from requesting count(*) as per now.


An extra optional sqlite_rowcount table costs so little that I don't 
see a motivation to put row count data elsewhere. Also keeping it 
separate doesn't preclude reading the DB with a previous version of SQLite.


It's just a $0.02 idea of course.

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Feature Request - RowCount

[Simon Slavin]

On 14 Dec 2014, at 11:08am, Jean-Christophe Deschamps  wrote:

> Without using slow triggers or changing the v3 file format there is still 
> another possibility which could be implemented relatively easily. All it 
> would need is a new pragma (or internal function) like "pragma row_count=0/1" 
> and some code.
> 
> On invokation, the engine would create a hidden "system" table like 
> sqlite_rowcount --similar to sqlite_sequence-- which would initially hold row 
> counts for every table in the DB.

Two obvious places:

A) In that sqlite_sequence table you mentioned, as an additional column.  
Always up-to-date.

B) In the tables prepared by SQLite ANALYZE.  If you want the rowcount updated, 
do another ANALYZE.

Simon.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Feature Request - RowCount

[Jean-Christophe Deschamps]

At 03:14 14/12/2014, you wrote:
´¯¯¯
I take the point that the only possible improvements seem to need 
alteration to the file structure or added maintenance which may use up 
cycles for something that just isn't that important to DB use in 
general - and I have to agree, I too have zero want for seeing more 
cycles used.

`---

I too generally don't have had a use for instant row counting of 
massive tables on a routine basis. It seems that currently the most 
transparent way to have an instant row count is to use triggers, which 
are well known to slow down things significantly, or rely on 
application code to monitor counts and store them in another table.


Without using slow triggers or changing the v3 file format there is 
still another possibility which could be implemented relatively easily. 
All it would need is a new pragma (or internal function) like "pragma 
row_count=0/1" and some code.


On invokation, the engine would create a hidden "system" table like 
sqlite_rowcount --similar to sqlite_sequence-- which would initially 
hold row counts for every table in the DB.


When parsing the schema, the mere existence of this table would trigger 
the update of this table in subsequent operations.


One can even imagine that it could be possible to remove entries from 
this table corresponding to tables which are not needing an instant 
count(*).


Disabling the feature would be as simple as negating the pragma or 
dropping the table.


This way, no operation would be significantly penalized unless this 
feature is actually used and the file format would remain identical.


Would this fit the v3 bill?

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Feature Request - RowCount

[RSmith]

On 2014/12/13 14:38, Richard Hipp wrote:
The "SELECT count(*) FROM table" query already has a special optimization in the b-tree layer to make it go faster.  You can see 
this by comparing the times of these queries:


 SELECT count(*) FROM table;
 SELECT count(*) FROM table WHERE 1;

The WHERE clause on the second query disables the optimization and so the second query should run slower.  The second query visits 
and partially decodes every row in the b-tree.  The first visits every leaf page of the b-tree, but it does nothing more than read 
the "number-of-entries" from the header of the page, add that value to the accumulating count, and then move on.


Thank you very much for the clear explanation and taking the time Richard. The proposed methods above are fast indeed, but not 
instant and I guess you will never satisfy everyone until everything works instantaneously. I take the point that the only possible 
improvements seem to need alteration to the file structure or added maintenance which may use up cycles for something that just 
isn't that important to DB use in general - and I have to agree, I too have zero want for seeing more cycles used. I was hoping 
there might be a way, but am satisfied there isn't and would like to hope out loud with Simon that this might be seen in SQLite4.


Thanks,
Ryan

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Feature Request - RowCount

[David Empson]

> On 14/12/2014, at 4:17 am, Simon Slavin  wrote:
> 
> 
> On 13 Dec 2014, at 12:38pm, Richard Hipp  wrote:
> 
>> Also, if there are indices available, SQLite attempts to count the smallest
>> index (it has to guess at which is the smallest by looking at the number
>> and declared datatypes of the columns) and counting the smallest index
>> instead, under the theory that a smaller index will involve less I/O.
> 
> Would it not be faster to just count the number of pages each index takes up 
> ?  Uh ... no.
> Wow.  You really don't like storing counts or sizes, do you ?

That wouldn't work, because leaf nodes in a B-tree contain a variable number of 
used entries. It is necessary to visit each leaf node to find out how many 
entries that page contains.

The reason for using the "smallest" index is that each leaf node will hopefully 
cover more records than the leaf nodes from the main table, therefore less I/O 
is required.

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Feature Request - RowCount

[Simon Slavin]

On 13 Dec 2014, at 7:46pm, James K. Lowden  wrote:

> Every DB Admin tool I've ever used proved to be more hinderance than
> help.  They seem to be written by the moderately competent to help the
> novice, and run out of gas or fall over when faced with anything
> complex.  [snip]
> 
> My first question, then, is whether or not the rowcount is so
> interesting that it must be known before a table can be operated on.
> I suggest the answer is No.  The relative & approximate sizes of the
> tables is known to the admin in most cases and, when it is not, the
> information is readily discovered on a case-by-case basis. [snip]

All true.  Yet when I wrote my own DB Admin tool (suitable only for my own use, 
of no interest to anyone else) I included the same feature in it.  When you 
click on a TABLE to select it the count(*) pops up along with information about 
the table's structure.  I had no real idea why I put that in, it just seemed a 
natural thing to do.

> That said, I'm puzzled why rowcount isn't maintained and exposed in
> SQLite as part of a table's metadata, particularly when indexes/keys are
> present.  The cost of maintaining a rowcount is small, in terms of
> computation and complexity.  ISTM it is valuable information to the
> system itself in evaluating query-plan costs.

It does seem that knowing count(*) would be a very good thing to know for 
evaluating query-plan costs.  I hope SQLite4 stores it.

Simon.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Feature Request - RowCount

[James K. Lowden]

On Sat, 13 Dec 2014 14:15:15 +0200
RSmith  wrote:

> Most DB Admin tools out there displays the number of rows in a table
> when you select it or open it, so too the one I am working on and
> after testing stuff on Simon's question about the row counting, I
> realised that selecting a large table always pauses somewhat (with
> suitable progress bar) to simply open and report the usual
> statistics. The culprit of course being row-counting.  

Every DB Admin tool I've ever used proved to be more hinderance than
help.  They seem to be written by the moderately competent to help the
novice, and run out of gas or fall over when faced with anything
complex.  So the number of tools with feature X is no measure of the
value of X.  (Notable example: the tool should keep every query and
result in a time-sequenced transcript log, so that prior results can be
re-examined and prior queries modified.  Most tools disassociate query
from output and invite the user to modify the query in-place,
destroying the prior.)  

My first question, then, is whether or not the rowcount is so
interesting that it must be known before a table can be operated on.
I suggest the answer is No.  The relative & approximate sizes of the
tables is known to the admin in most cases and, when it is not, the
information is readily discovered on a case-by-case basis.  

Would a proxy figure do?  Is it enough to know the number of pages or
bytes allocated to a table?  I don't know if such is available, but if
it is perhaps that would serve your purpose.  Otherwise your user
might be satisfied by lazy evaluation: run your count(*) query on a
fork and provide the answer through a pipe or similar, in such a way
that the user can cancel it if it's placing too high a load on the
system.  

That said, I'm puzzled why rowcount isn't maintained and exposed in
SQLite as part of a table's metadata, particularly when indexes/keys are
present.  The cost of maintaining a rowcount is small, in terms of
computation and complexity.  ISTM it is valuable information to the
system itself in evaluating query-plan costs.  The "because it's lite"
argument doesn't hold water insofar as applications are paying a high
cost (even if somewhat optimized) for a common query.  

--jkl
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Feature Request - RowCount

[Richard Hipp]

No.  The fastest is to do "count(*)".

--
D. Richard Hipp
Sent from phone - Excuse brevity
On Dec 13, 2014 11:13 AM, "Jim Callahan" 
wrote:

> So, if I understand the discussion the fastest way to get a count from the
> command line interface (CLI) is to count the rows in the primary key,
> assuming you have a primary key and that it is not a composite key.
>
> SELECT COUNT(primarykey) FROM table1
>
> The "primarykey" in the above example is a stand in  for the actual name of
> the field designated as the primary key.
>
> I am also relying on the answers to FAQ #1 and #26.
>
> #26 The unique columns have non-null values (the answer says a lot more,
> but that is the essence of what I am relying on).
>
> #1 If you have an integer primary key (which by definition in SQLITE3
> autoincrements) one might be able to get an approximate row count faster
> using the:
>
> sqlite3_last_insert_rowid()
>
> function.
>
> Jim Callahan
> Orlando, FL
>
> On Dec 13, 2014 10:17 AM, "Simon Slavin"  wrote:
>
> >
> > On 13 Dec 2014, at 12:38pm, Richard Hipp  wrote:
> >
> > > Also, if there are indices available, SQLite attempts to count the
> > smallest
> > > index (it has to guess at which is the smallest by looking at the
> number
> > > and declared datatypes of the columns) and counting the smallest index
> > > instead, under the theory that a smaller index will involve less I/O.
> >
> > Would it not be faster to just count the number of pages each index takes
> > up ?  Uh ... no.
> > Wow.  You really don't like storing counts or sizes, do you ?
> >
> > > To do better than this requires, as far as I know, an incompatible file
> > > format change and/or a performance hit for applications that do not use
> > the
> > > feature.
> >
> > Can you tell us whether the problem exists in SQLite4 ?  I know it uses a
> > different format for indexes.  I tried checking the documentation but
> > didn't see an answer that didn't involve more work than I felt like
> doing.
> >
> > Simon.
> > ___
> > 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
>
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Feature Request - RowCount

[Jim Callahan]

So, if I understand the discussion the fastest way to get a count from the
command line interface (CLI) is to count the rows in the primary key,
assuming you have a primary key and that it is not a composite key.

SELECT COUNT(primarykey) FROM table1

The "primarykey" in the above example is a stand in  for the actual name of
the field designated as the primary key.

I am also relying on the answers to FAQ #1 and #26.

#26 The unique columns have non-null values (the answer says a lot more,
but that is the essence of what I am relying on).

#1 If you have an integer primary key (which by definition in SQLITE3
autoincrements) one might be able to get an approximate row count faster
using the:

sqlite3_last_insert_rowid()

function.

Jim Callahan
Orlando, FL

On Dec 13, 2014 10:17 AM, "Simon Slavin"  wrote:

>
> On 13 Dec 2014, at 12:38pm, Richard Hipp  wrote:
>
> > Also, if there are indices available, SQLite attempts to count the
> smallest
> > index (it has to guess at which is the smallest by looking at the number
> > and declared datatypes of the columns) and counting the smallest index
> > instead, under the theory that a smaller index will involve less I/O.
>
> Would it not be faster to just count the number of pages each index takes
> up ?  Uh ... no.
> Wow.  You really don't like storing counts or sizes, do you ?
>
> > To do better than this requires, as far as I know, an incompatible file
> > format change and/or a performance hit for applications that do not use
> the
> > feature.
>
> Can you tell us whether the problem exists in SQLite4 ?  I know it uses a
> different format for indexes.  I tried checking the documentation but
> didn't see an answer that didn't involve more work than I felt like doing.
>
> Simon.
> ___
> 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

Re: [sqlite] Feature Request - RowCount

[Simon Slavin]

On 13 Dec 2014, at 12:38pm, Richard Hipp  wrote:

> Also, if there are indices available, SQLite attempts to count the smallest
> index (it has to guess at which is the smallest by looking at the number
> and declared datatypes of the columns) and counting the smallest index
> instead, under the theory that a smaller index will involve less I/O.

Would it not be faster to just count the number of pages each index takes up ?  
Uh ... no.
Wow.  You really don't like storing counts or sizes, do you ?

> To do better than this requires, as far as I know, an incompatible file
> format change and/or a performance hit for applications that do not use the
> feature.

Can you tell us whether the problem exists in SQLite4 ?  I know it uses a 
different format for indexes.  I tried checking the documentation but didn't 
see an answer that didn't involve more work than I felt like doing.

Simon.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Feature Request - RowCount

[Richard Hipp]

The "SELECT count(*) FROM table" query already has a special optimization
in the b-tree layer to make it go faster.  You can see this by comparing
the times of these queries:

 SELECT count(*) FROM table;
 SELECT count(*) FROM table WHERE 1;

The WHERE clause on the second query disables the optimization and so the
second query should run slower.  The second query visits and partially
decodes every row in the b-tree.  The first visits every leaf page of the
b-tree, but it does nothing more than read the "number-of-entries" from the
header of the page, add that value to the accumulating count, and then move
on.

Also, if there are indices available, SQLite attempts to count the smallest
index (it has to guess at which is the smallest by looking at the number
and declared datatypes of the columns) and counting the smallest index
instead, under the theory that a smaller index will involve less I/O.

To do better than this requires, as far as I know, an incompatible file
format change and/or a performance hit for applications that do not use the
feature.  I considered including in the SQLite file format the ability to
discover the rank of an entry in the b-tree in logarithmic time.  In other
words, give any row X, to find the number of rows less than X in the
table.  That ability would all the "SELECT count(*) FROM table" query to
run in logarithmic time simply by seeking to the last entry of the table
and finding its rank.  But, I rejected that idea because (1) it takes up
extra space in the database file meaning that queries have to read a little
more data and so run slightly slower and (2) because there is a significant
amount of extra writing on an update because every parent node in the
b-tree must be updated whenever any of its children is updated.  You can
argue that I made a bad decision in omitting this capability, but others
might argument to the contrary, and in any event, that decision was made 10
years ago and cannot be changed without a file format break.

On Sat, Dec 13, 2014 at 7:15 AM, RSmith  wrote:
>
> To the SQLite devs:
>
> After recent discussion about the row-count issue w.r.t. Nulls in primary
> keys etc. I have been somewhat wrestling with how to improve this from a
> user perspective.
>
> To explain: Most DB Admin tools out there displays the number of rows in a
> table when you select it or open it, so too the one I am working on and
> after testing stuff on Simon's question about the row counting, I realised
> that selecting a large table always pauses somewhat (with suitable progress
> bar) to simply open and report the usual statistics. The culprit of course
> being row-counting.  The problem escalates with bigger tables and most
> users detest sluggishness and all of us try to make things less so.
>
> I thought of keeping the count cached, which works while the connection is
> open, but becomes useless if re-opened (another app may have changed that
> in the meantime - actually this may even have happened while the connection
> is open). I've also tried cheating by inspecting the file size and upon big
> enough files, defer row-counting with some form of [This is a large DB -
> Click here to check the row count, this may take some time.] user message
> where the row-count is supposed to appear - but as you must be aware I have
> run across DBs several GBs in size with only a few hundred-K rows in the
> large tables, and one DB I have weighs in at only 250MB but have about
> 11mil rows in the main table. Not to mention the fact that one table might
> have all the rows and the others may all be small.
>
> To address the table-walk for Indices containing NULLs: Most DB admins and
> system engineers are savvy to this problem, I am sure in over 90% of the
> cases they do not keep NULLs in primary keys even if SQLite allows this. (I
> think the figure is over 99% but I am weary of exaggeration) - but even if
> they do have NULLs, sometimes you just need to know the amount of rows, not
> the amount of non-NULL value rows. I realise this cannot fit in an
> algebraically verifyable SQL result such as count() because of those few
> cases, but a possible pragma can fix it for the rest of us.
>
> I realise this problem is rather specific to the DB admin programs as
> opposed to user systems, but a Pragma "rowcount(TableName);" would be
> spectacular where the count is simply a fast reference to the total rows
> regardless of content with documentation pointing out the difference.
>
> I am very willing to submit a documentation draft if this feature gets
> added (to save someone some work) but I am not versed well enough in the
> SQLite internals to attempt a patch. Also, the solution needn't fall upon
> my suggestion, any other suitable means of making row count
> fast-determinable would be welcome.
>
>
> Thank you kindly,
> Ryan
>
>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> 

[sqlite] Feature Request - RowCount

[RSmith]

To the SQLite devs:

After recent discussion about the row-count issue w.r.t. Nulls in primary keys etc. I have been somewhat wrestling with how to 
improve this from a user perspective.


To explain: Most DB Admin tools out there displays the number of rows in a table when you select it or open it, so too the one I am 
working on and after testing stuff on Simon's question about the row counting, I realised that selecting a large table always pauses 
somewhat (with suitable progress bar) to simply open and report the usual statistics. The culprit of course being row-counting.  The 
problem escalates with bigger tables and most users detest sluggishness and all of us try to make things less so.


I thought of keeping the count cached, which works while the connection is open, but becomes useless if re-opened (another app may 
have changed that in the meantime - actually this may even have happened while the connection is open). I've also tried cheating by 
inspecting the file size and upon big enough files, defer row-counting with some form of [This is a large DB - Click here to check 
the row count, this may take some time.] user message where the row-count is supposed to appear - but as you must be aware I have 
run across DBs several GBs in size with only a few hundred-K rows in the large tables, and one DB I have weighs in at only 250MB but 
have about 11mil rows in the main table. Not to mention the fact that one table might have all the rows and the others may all be small.


To address the table-walk for Indices containing NULLs: Most DB admins and system engineers are savvy to this problem, I am sure in 
over 90% of the cases they do not keep NULLs in primary keys even if SQLite allows this. (I think the figure is over 99% but I am 
weary of exaggeration) - but even if they do have NULLs, sometimes you just need to know the amount of rows, not the amount of 
non-NULL value rows. I realise this cannot fit in an algebraically verifyable SQL result such as count() because of those few cases, 
but a possible pragma can fix it for the rest of us.


I realise this problem is rather specific to the DB admin programs as opposed to user systems, but a Pragma "rowcount(TableName);" 
would be spectacular where the count is simply a fast reference to the total rows regardless of content with documentation pointing 
out the difference.


I am very willing to submit a documentation draft if this feature gets added (to save someone some work) but I am not versed well 
enough in the SQLite internals to attempt a patch. Also, the solution needn't fall upon my suggestion, any other suitable means of 
making row count fast-determinable would be welcome.



Thank you kindly,
Ryan


___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users