>> The count(*) information can be revisioned too, am I wrong ? I'm able
>> to create a trigger that store the count(*) information in a special
>> table, why not implement the same in a way "builded in" ?
>
> Then every insert or delete would have to lock that count. Nobody else
> would be able to insert or delete any records until you either commit or
> roll back.
>
> That would lead to much lower concurrency, much more contention for
> locks, and tons of deadlocks.
What about queueing all these updates for a separate low-priority
thread? The thread would be the only one with access to update this field.
--
Randolf Richardson - rr@8x.ca
Vancouver, British Columbia, Canada
Please do not eMail me directly when responding
to my postings in the newsgroups.
