On Wed, Oct 1, 2008 at 5:26 PM, Martijn Tonies <m.tonies@...> wrote:

>
>> >> 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.

Thank you,
Timothy Madden