Subject | Re: If Not SELECT COUNT(*), Then What? |
---|---|
Author | inoffensive_2009 |
Post date | 2008-12-10T11:20:55Z |
--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...> wrote:
can know ahead of time how many records there are going to be - as
e.g. for a progress bar - then that's inefficient. But there are
still a lot of people out there writing apps like that....and
complaining about Firebird's performance... ;-)
Thanks Martijn, Dimitry and Helen:
This is, in fact, about displaying a progress window.
I start a transaction, then get the count of records to
be read, and display that. Then I run the select, updating
the display of records read after every 100 fetches, and
then I commit the transaction.
This application is currently using the embedded server,
so at this time the database won't be changed. And if it
is, so what? We have to start a transaction at some point,
and if the
So I am using this count for exactly the application you
say is inefficient. How would you do this?
Thanks
Larry
>test.
> At 09:14 PM 10/12/2008, you wrote:
> >Hi Folks:
> >
> > I had a bug in a function that is passed a table
> >name and a where clause, and returns a count of the
> >records that qualify for the where clause, if one is
> >passed in.
> >
> > The function builds an SQL of
> >
> > SELECT
> > COUNT(*) FROM
> > <Table Name>
> > WHERE <--------- If where clause passed in
> > <Where Clause>;
> >
> > While tracking down the problem I read in Helen's
> >book that SELECT COUNT(*) is inefficient.
>
> It's an inefficient (and not very safe) way to perform an existence
>to count things. But if the idea is to count all the records so you
>
> > Should I re-think the use of COUNT(*) in this function?
>
> As long as you *need* it to COUNT things, no, there's no other way
can know ahead of time how many records there are going to be - as
e.g. for a progress bar - then that's inefficient. But there are
still a lot of people out there writing apps like that....and
complaining about Firebird's performance... ;-)
Thanks Martijn, Dimitry and Helen:
This is, in fact, about displaying a progress window.
I start a transaction, then get the count of records to
be read, and display that. Then I run the select, updating
the display of records read after every 100 fetches, and
then I commit the transaction.
This application is currently using the embedded server,
so at this time the database won't be changed. And if it
is, so what? We have to start a transaction at some point,
and if the
So I am using this count for exactly the application you
say is inefficient. How would you do this?
Thanks
Larry