Subject | Firebird 2.0 Indexing |
---|---|
Author | buppcpp |
Post date | 2005-05-29T11:18:29Z |
Were the changes to the indexes in 2.0 suppose to provide more than
larger indexes?
The reason I'm asking is because some of my queries still run just
as slow in 2.0 as they did 1.5.2.
Ex. SELECT distinct store_no from mytable; (Does a table scan)
mytable has 2.1 million records with an index on store_no.
It takes 3.32 minutes to run.
On the database I want to convert from, it takes 15 secs. (Data is
exactly the same between the two databases)
SELECT * from mytable where store_no > 2; (Uses store_no index)
It takes 3.27 minutes
On the database I want to convert from, it takes 1.57 minutes.
This is a freshly restored DB.
Will these types of indexing issues be taken care of 2.0, if not,
when?
I for one would prefer to have the indexing system fixed in 2.0,
because I think we may need to sit on it for awhile, while 3.0 gets
all of it's bugs knocked out. Plus, 3.0 will have the same
problems, if it's not taken care of now, but with the overhead of
SMP code (for 1 CPU systems).
Thanks
P.S. My restore time was cut in half from 50 mins on 1.5.2 to 26
min with 2.0 !! (DB Size 2.6 Gig)
System Specs:
WinXP Pro. SP 2
2.6 MHZ
512 MB RAM
ODSVersion = 11.0
Charset = NONE
PageSize = 8192
PageBuffers = 32768
SQLDialect = 3
SweepInterval = 20000
ForcedWrites = False
ReadOnly = False
larger indexes?
The reason I'm asking is because some of my queries still run just
as slow in 2.0 as they did 1.5.2.
Ex. SELECT distinct store_no from mytable; (Does a table scan)
mytable has 2.1 million records with an index on store_no.
It takes 3.32 minutes to run.
On the database I want to convert from, it takes 15 secs. (Data is
exactly the same between the two databases)
SELECT * from mytable where store_no > 2; (Uses store_no index)
It takes 3.27 minutes
On the database I want to convert from, it takes 1.57 minutes.
This is a freshly restored DB.
Will these types of indexing issues be taken care of 2.0, if not,
when?
I for one would prefer to have the indexing system fixed in 2.0,
because I think we may need to sit on it for awhile, while 3.0 gets
all of it's bugs knocked out. Plus, 3.0 will have the same
problems, if it's not taken care of now, but with the overhead of
SMP code (for 1 CPU systems).
Thanks
P.S. My restore time was cut in half from 50 mins on 1.5.2 to 26
min with 2.0 !! (DB Size 2.6 Gig)
System Specs:
WinXP Pro. SP 2
2.6 MHZ
512 MB RAM
ODSVersion = 11.0
Charset = NONE
PageSize = 8192
PageBuffers = 32768
SQLDialect = 3
SweepInterval = 20000
ForcedWrites = False
ReadOnly = False