Subject | Re: [ib-support] Why is Count(*) slow? |
---|---|
Author | Ann W. Harrison |
Post date | 2001-09-07T14:00:30Z |
At 02:27 PM 9/7/2001 +0300, raptor wrote:
touching the actual data. They just count the number of entries in the
primary key index - or any other index for that matter. Some actually
keep a count for each table, but that creates serious contention on the
count and reduces overall performance.
A multi-generational database like Firebird, which uses back versions of
records as the recovery log & consistent snapshot must examine each record
because the index may contain more than one entry for records that have
been modified, as well as entries for records which have been deleted but
which are kept as part of a snapshot. Firebird performs a "natural" scan
of the table, counting only those records that are visible to the current
transaction.
COUNT(*), COUNT(''), and COUNT(<column>) are all equivalent in performance,
though COUNT (<column>) counts only those rows that have a non-null value
for <column>.
If anyone would like to know why keeping the transaction id in the index
doesn't solve this problem, go meet me in the list ib-architect.
Regards,
Ann
www.ibphoenix.com
We have answers.
>I've seen post on the list that COUNT(*) is slow, and that possiblyThis is worth repeating. Most databases can execute a "count" without
>COUNT('') is faster...
>Can someone shine me on this... provate mail is OK... to not clutter the
>list..
touching the actual data. They just count the number of entries in the
primary key index - or any other index for that matter. Some actually
keep a count for each table, but that creates serious contention on the
count and reduces overall performance.
A multi-generational database like Firebird, which uses back versions of
records as the recovery log & consistent snapshot must examine each record
because the index may contain more than one entry for records that have
been modified, as well as entries for records which have been deleted but
which are kept as part of a snapshot. Firebird performs a "natural" scan
of the table, counting only those records that are visible to the current
transaction.
COUNT(*), COUNT(''), and COUNT(<column>) are all equivalent in performance,
though COUNT (<column>) counts only those rows that have a non-null value
for <column>.
If anyone would like to know why keeping the transaction id in the index
doesn't solve this problem, go meet me in the list ib-architect.
Regards,
Ann
www.ibphoenix.com
We have answers.