|Subject||Re: So confused|
|Author||Svein Erling Tysvær|
> > > SELECTEither this is the case (and should be fixed), or he can solve his
> > > v.ID, e.nodeID, e.ID, a.MD5
> > > FROM Elems e
> > > JOIN ENames n ON n.ID = e.nameID
> > > JOIN EVers v
> > > ON v.elementId = e.ID AND v.ID = e.lastVersionID
> > > JOIN EAttribs a ON a.ID = v.attribsID
> > > WHERE
> > > e.nodeID = ? /* -9223372036853775797 */
> > Oddly enough, this still does a NATURAL on "Enames n" for me.
> > Hmmm...there is plenty of data in ENames to warrant the use of the
> > Primary Key Index. And enames has one other index on it, basically
> > an index of the Digests of the display name -- it's a unique
> > index.
> One thing I have just thought of, have you by accident created an
> index on the PK field of enames? PKs and FKs automatically add an
> index for you, and for some reason the optimiser can get very
> confused if two identical indexes are available, and it makes the
> worst possible decision (to use neither).
problems by doing the two changes I recommended in
Remember, he is using Firebird 1.0.3 that needed more tweaking than
the current 1.5.3 version.