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

Either this is the case (and should be fixed), or he can solve his
problems by doing the two changes I recommended in
http://groups.yahoo.com/group/firebird-support/message/65232.
Remember, he is using Firebird 1.0.3 that needed more tweaking than
the current 1.5.3 version.

Set