Subject | Re: Firebird 2.0 Indexing |
---|---|
Author | buppcpp |
Post date | 2005-05-30T12:08:30Z |
What I am suggesting is this...
I want Firebird to become the best on the market.
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.
Thanks
--- In firebird-support@yahoogroups.com, Kjell Rilbe
<kjell.rilbe@a...> wrote:
I want Firebird to become the best on the market.
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.
Thanks
--- In firebird-support@yahoogroups.com, Kjell Rilbe
<kjell.rilbe@a...> wrote:
> buppcpp wrote:types
>
> > It has nothing to do with normalization, store_no is part of a 2
> > field primary key.
> >
> > But instead of wondering why another database can handle these
> > of queries so fast and Firebird can't, and what we can do toto
> > possible make Firebird run better in these situations, you want
> > try to belittle the person that is looking for answers.been
>
> Ok, you've both been trying hard not to understand one another.
>
> You've been given explanations of how Firebird works and you've
> suggested to consider a different solution to what you're tryingto -
> one that does not require a scan of 2+ million records to returnfive.
>work
> You're obviously not a DB novice, so I suggest you give this some
> thought and when you've come up with a couple of ideas that would
> in your application, ask here if you need help to assess if theyare
> good ways forward with FB.
>
> We can't help you if you don't give us complete info about your
> application and data structures.
>
> Kjell
> --
> --------------------------------------
> Kjell Rilbe
> Adressmarknaden AM AB
> E-post: kjell.rilbe@a...
> Telefon: 08-761 06 55
> Mobil: 0733-44 24 64