Subject | Re: [Firebird-general] Re: History of Interbase's failure to make |
---|---|
Author | Dmitry Yemanov |
Post date | 2005-10-20T05:55:10Z |
"Robert martin" <rob@...> wrote:
info (transaction number or any other marker) or not. Most of DBMS evaluate
count() via a PK index scan. For a blocking engines, this works. In Oracle,
this works too (there's no version info at the row/node level). This doesn't
work in Firebird, as we don't have transaction ids in index nodes. IMO, it
shouldn't work in PG either (I hope Ann will correct me, if I'm wrong).
Never tested MySQL+InnoDB, so I don't have a clue here. As for Yukon, the MS
people still cannot provide any useful technical info about how their MVCC
indices work.
Dmitry
>It depends on only one answer - whether an index node contains a version
> I never realised how many other DBs were implementing an MGA
> architecture. One of FBs weaknesses has been with Select Count()...
> statements. It has always been blamed on the fact that FB is MGA and
> 'Other' faster DB is not. If the others are MGA as well is the select
> Count() really a FB issue NOT and MGA issue?
info (transaction number or any other marker) or not. Most of DBMS evaluate
count() via a PK index scan. For a blocking engines, this works. In Oracle,
this works too (there's no version info at the row/node level). This doesn't
work in Firebird, as we don't have transaction ids in index nodes. IMO, it
shouldn't work in PG either (I hope Ann will correct me, if I'm wrong).
Never tested MySQL+InnoDB, so I don't have a clue here. As for Yukon, the MS
people still cannot provide any useful technical info about how their MVCC
indices work.
Dmitry