Subject | Re: [firebird-support] Re: Firebird 2.0 Indexing |
---|---|
Author | Kjell Rilbe |
Post date | 2005-06-02T05:11:04Z |
buppcpp wrote:
relevant to FB. As has been pointed out before, you're not giving us the
full picture.
more than one suggestion of improved DB design that would improve
performance on FB (and probably on your current engine too) to probably
less than a second. Why not give that a shot?
I've been telling another poster that he wasn't really being helpful,
but I have to say that there's more than one dog in this dog fight.
Please stop the hostility that's inherent in the way you write and argue
the issues and try to embrace the help you've actually received. The
fact is that any given DB engine will have it's quirks. You've stumbled
upon a case where FB doen't do an excellent job, but there are
workarounds that are not only good for performance in FB but actually
make a lot of sense in theoretical DB design aspects too (the store_no
should be a lookup).
Kjell
--
--------------------------------------
Kjell Rilbe
Adressmarknaden AM AB
E-post: kjell.rilbe@...
Telefon: 08-761 06 55
Mobil: 0733-44 24 64
> This is 1 example of a customers database, I have thousands of otherRelevant for your current DB engine. That's not a gurantee that it's
> customers where this index is relavent.
relevant to FB. As has been pointed out before, you're not giving us the
full picture.
> Besides, my current database uses it in my example query and isIs 15 seconds really "lighning fast" for this query? You've been giving
> lightning fast compared to Firebird.
more than one suggestion of improved DB design that would improve
performance on FB (and probably on your current engine too) to probably
less than a second. Why not give that a shot?
I've been telling another poster that he wasn't really being helpful,
but I have to say that there's more than one dog in this dog fight.
Please stop the hostility that's inherent in the way you write and argue
the issues and try to embrace the help you've actually received. The
fact is that any given DB engine will have it's quirks. You've stumbled
upon a case where FB doen't do an excellent job, but there are
workarounds that are not only good for performance in FB but actually
make a lot of sense in theoretical DB design aspects too (the store_no
should be a lookup).
Kjell
--
--------------------------------------
Kjell Rilbe
Adressmarknaden AM AB
E-post: kjell.rilbe@...
Telefon: 08-761 06 55
Mobil: 0733-44 24 64