jllachan@nsd.ca (Jean-Luc Lachance) writes:
> That's one of the draw back of MVCC.
> I once suggested that the transaction number and other house keeping
> info be included in the index, but was told to forget it...
> It would solve once and for all the issue of seq_scan vs index_scan.
> It would simplify the aggregate problem.
It would only simplify _one_ case, namely the case where someone cares
about the cardinality of a relation, and it would do that at
_considerable_ cost.
A while back I outlined how this would have to be done, and for it to
be done efficiently, it would be anything BUT simple.
It would be very hairy to implement it correctly, and all this would
cover is the single case of "SELECT COUNT(*) FROM SOME_TABLE;"
If you had a single WHERE clause attached, you would have to revert to
walking through the tuples looking for the ones that are live and
committed, which is true for any DBMS.
And it still begs the same question, of why the result of this query
would be particularly meaningful to anyone. I don't see the
usefulness; I don't see the value of going to the considerable effort
of "fixing" this purported problem.
--
let name="cbbrowne" and tld="libertyrms.info" in String.concat "@" [name;tld];;
<http://dev6.int.libertyrms.com/>
Christopher Browne
(416) 646 3304 x124 (land)
