Subject | Re: [firebird-support] Sloow query |
---|---|
Author | Svein Erling Tysvaer |
Post date | 2003-06-26T10:16:32Z |
Good to hear that your execution time is improving, Louis (so I removed two
'oo's from your subject). What would be helpful for any further
improvement, would be to know the chosen plan and how many records match
each requirement within the plan. What I'm thinking of is that now you've
got indexes that does improve your select, but it may be that you have too
many indexes and that only having some of them would be better than having
all (or - more likely - try to 'disable' some of them in this very query).
I don't think we can match MySQL, Firebird is much more of a proper
client/server database than MySQL and I think MySQL makes shortcuts that
are simply impossible to do for a c/s database having a multigenerational
architecture, but maybe we can get closer.
And what Milan says is true.
Set
At 11:27 26.06.2003 +0200, you wrote:
'oo's from your subject). What would be helpful for any further
improvement, would be to know the chosen plan and how many records match
each requirement within the plan. What I'm thinking of is that now you've
got indexes that does improve your select, but it may be that you have too
many indexes and that only having some of them would be better than having
all (or - more likely - try to 'disable' some of them in this very query).
I don't think we can match MySQL, Firebird is much more of a proper
client/server database than MySQL and I think MySQL makes shortcuts that
are simply impossible to do for a c/s database having a multigenerational
architecture, but maybe we can get closer.
And what Milan says is true.
Set
At 11:27 26.06.2003 +0200, you wrote:
>songlist.ID is a primary key and I just make an index for
>categorylist.songID as well as songlist.date_played and date_artist_played
>
>This made the query execute in 2.4 seconds. A lot better...
>But still not near the 0.1sec I'm used to with MySQL :(