Subject | Re: [firebird-support] What programming languages and toolkits do you use to access Firebird? |
---|---|
Author | Alexandre Benson Smith |
Post date | 2008-10-01T15:10:19Z |
Timothy Madden wrote:
clause it has been shown how could be done with a table that holds
summarized counts, aggregate from time to time and triggers to add +1 or
-1 and sum it up. It's fast, reliable and easy !
If he needs to process 8 million rows I think the process would be long
enough so waiting 12s for the count should not be the problem.
The problem IMO is that there is always a WHERE clause or JOIN's
involved, so a simple record count per table has no meaning at all.
--
Alexandre Benson Smith
Development
THOR Software e Comercial Ltda
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br
> On Wed, Oct 1, 2008 at 5:26 PM, Martijn Tonies <m.tonies@...> wrote:If he needs a full reliable count of the *full* table without a WHERE
>
>>>>> This SELECT Count(*) problem is really incredible. I can understand
>>>>> concurent
>>>>> transactions see different versions of the same table. Why is it
>>>>> difficult for every
>>>>> of these versions to also have their own row count ?
>>>>>
>>>> Because such count would have to be kept in system tables, and it would
>>>> mean versioning system tables - which has proven to be tricky so far.
>>>>
>>> How about letting the system tables reflect the base version of the table
>>>
>> and
>>
>>> put the per-transaction row-count toghether with the version-specific data
>>>
>> of
>>
>>> the table ?
>>>
>> No offence, but this only makes sense if you do a "select count(*) from
>> table".
>>
>> That is: no specific columns (cause then the result can be different), no
>> WHERE
>> clause.
>>
>> Why go through all this trouble for something that is, per transaction,
>> hardly in use?
>>
>
> Well, the OP seems to want his tables displayed in some grid control,
> which needs a scroll bar, and someone else reported an 8 milion rows
> table needs about 12s to get the row count.
>
> I believe many applications can be made to work without reading the row
> count in advance, and I would do this every time I can, but if I need the
> row count for a base table I would still expect to have it in a reasonable
> amount of time.
>
clause it has been shown how could be done with a table that holds
summarized counts, aggregate from time to time and triggers to add +1 or
-1 and sum it up. It's fast, reliable and easy !
If he needs to process 8 million rows I think the process would be long
enough so waiting 12s for the count should not be the problem.
The problem IMO is that there is always a WHERE clause or JOIN's
involved, so a simple record count per table has no meaning at all.
> Thank you,see you !
> Timothy Madden
>
>
--
Alexandre Benson Smith
Development
THOR Software e Comercial Ltda
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br