| Subject | Re: [firebird-support] Re: Firebird 2.0 Indexing |
|---|---|
| Author | Kjell Rilbe |
| Post date | 2005-05-30T12:33:17Z |
buppcpp wrote:
team should consider ways to improve it, but you should also consider
changing your application and/or data model to make it work well with
Firebird. There's no such thing as a totally generic DB engine that
performs well in all situations. You have to adapt your application to
the engine you choose, or live with the drawbacks of not doing so. That
said, I do have a general feeling that Firebird requires more such
adaptation to work well than does for example SQL Server, but I don't
have any figures to back it up.
In this particular case, I would assume that it would be possible to
have FB scan the appropriate index (an index on the selected column) and
for each distinct value in the index, keep looking up records until 1)
it finds one that's visible to the current transaction (the value is
included in the result set) or 2) the scan is complete (the value is
excluded from the result set). This type of scan should be used for low
selectivity indices, while it would probably be better to perform a
natural scan for high-selectivity ones (or where no index is available).
Perhaps this is the way it currently works, perhaps it isn't. I don't
know. If it isn't, it would be interesting if someone from the FB dev
team could explain if it would be possible and if it would be a good
idea. I would certainly not expect it to be implemented in 2.0 since
it's already in alpha.
Kjell
--
--------------------------------------
Kjell Rilbe
Adressmarknaden AM AB
E-post: kjell.rilbe@...
Telefon: 08-761 06 55
Mobil: 0733-44 24 64
> I want Firebird to become the best on the market.I share your view that if Firebird performs badly in a situation the
>
> I came across a situation where Firebird looked pretty bad in
> comparison to what I would consider an inferior database.
>
> I was hoping that this was a know issue that was being worked on
> right along with the new indexing scheme, and if not, then it should
> be something that should definitely be looked into for 2.0 if not
> 1.5.
>
> So, I still believe that queries with "DISTINCT" needs to be
> enhanced, because crappy databases are "blowing it out of the
> water", under these conditions, and this is the right time to look
> into it.
team should consider ways to improve it, but you should also consider
changing your application and/or data model to make it work well with
Firebird. There's no such thing as a totally generic DB engine that
performs well in all situations. You have to adapt your application to
the engine you choose, or live with the drawbacks of not doing so. That
said, I do have a general feeling that Firebird requires more such
adaptation to work well than does for example SQL Server, but I don't
have any figures to back it up.
In this particular case, I would assume that it would be possible to
have FB scan the appropriate index (an index on the selected column) and
for each distinct value in the index, keep looking up records until 1)
it finds one that's visible to the current transaction (the value is
included in the result set) or 2) the scan is complete (the value is
excluded from the result set). This type of scan should be used for low
selectivity indices, while it would probably be better to perform a
natural scan for high-selectivity ones (or where no index is available).
Perhaps this is the way it currently works, perhaps it isn't. I don't
know. If it isn't, it would be interesting if someone from the FB dev
team could explain if it would be possible and if it would be a good
idea. I would certainly not expect it to be implemented in 2.0 since
it's already in alpha.
Kjell
--
--------------------------------------
Kjell Rilbe
Adressmarknaden AM AB
E-post: kjell.rilbe@...
Telefon: 08-761 06 55
Mobil: 0733-44 24 64