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

Martijn Tonies
Database Workbench - tool for InterBase, Firebird, MySQL, NexusDB, Oracle &
MS SQL Server
Upscene Productions
http://www.upscene.com
My thoughts:
http://blog.upscene.com/martijn/
Database development questions? Check the forum!
http://www.databasedevelopmentforum.com