On Wed, Oct 1, 2008 at 5:43 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?
>
> As I said...
>
>> 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.
>
> This is the -single- situation where this would make sense. It won't
> ever ever make any sense outside this particular situation cause
> normally you would display a resultset of a query, which hardly ever
> is a complete display of all rows from a single table.
>
>> 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.

Ok, ok.
I do not really have this problem, I was just saying what my expectations
would be.

But does the engine not need this information internally during all sort of
queries ?

Thank you,
Timothy Madden