On 5 March 2016 at 23:52, Paul Sanderson
wrote:
> That doesn't work for me:
>
> I am trying to avoid (select col1, col2, ... colx ) from ...
>
> and want just a row count which is much less resource intensive.
>
Have you measured this? I think you might be surprised as sqlite doesn't
keep track
So
select count (*) from ...
Doesn't require a crystal ball and returns the number of rows but
Select count(*) from ... Limit x
Dies need one, interesting
On Saturday, 5 March 2016, Igor Tandetnik wrote:
> On 3/5/2016 12:20 PM, Paul Sanderson wrote:
>
>> If it computes many things and doesn'
On 3/5/2016 7:15 PM, Paul Sanderson wrote:
> So
>
> select count (*) from ...
>
> Doesn't require a crystal ball and returns the number of rows
It does however fail to satisfy "before I execute it in full"
requirement. It essentially does execute the inner query in full, while
counting the rows
Paul Sanderson wrote:
> I have users who need to execute queries that generate a large number
> of rows, I have other users that create queries that generate a large
> number of rows by accident (i.e. cross joins). I have no control over
> what they enter but I want to do something to warn them tha
> Just allow them to cancel the query; use sqlite3_progress_handler().
I am using a third party data access component so this is out of my control.
If it computes many things and doesn't return many rows then I don't
really care. I only want to know how many rows a query will return
before I exec
On 3/5/2016 12:20 PM, Paul Sanderson wrote:
> If it computes many things and doesn't return many rows then I don't
> really care. I only want to know how many rows a query will return
> before I execute it in full.
That would require a crystal ball or a time machine. Absent those, it's
impossible
That doesn't work for me:
I am trying to avoid (select col1, col2, ... colx ) from ...
and want just a row count which is much less resource intensive.
I have users who need to execute queries that generate a large number
of rows, I have other users that create queries that generate a large
numb
Paul Sanderson wrote:
> I am trying to determine before a query is executed how many rows will
> be returned. the following query works as expected
>
> select count(*) from table
>
> but
>
> select count(*) from table limit 100
>
> still returns the number of rows in the table not the number of row
I am trying to determine before a query is executed how many rows will
be returned. the following query works as expected
select count(*) from table
but
select count(*) from table limit 100
still returns the number of rows in the table not the number of rows
that would be returned by the query.
9 matches
Mail list logo