> Is the database that you're converting from a desktop database

(like

> Access or Paradox)? They work nicely on tables, as opposed to

datasets

> which Firebird and other client/server databases prefer.

No, the database is a true client/server SQL database.

> Besides, three and a half minutes to return rows that people will

use

> months to examine isn't too long in my honest opinion. With 2.1
> million rows, that means 9900 rows per second! And I doubt the
> developers will be tempted to remove the multigenerational
> architecture to make it easier for people not wanting to adopt to

a

> client/server mindset.

3.5 minutes compared to 15 secs IS NOT TOO LONG!?! I would love to
see how your customer react when they take such a hht in performance!

And stop making assumptions about client/server mindsets.

>I cannot understand why anyone would
> want to run a statement without a where clause on a million-row

table

> (well, possibly if there were some kind of grouping reducing the
> returned set to a few rows)

My query does only return a few records from the table, I'm using
a 'distinct' clause.



--- In firebird-support@yahoogroups.com, Svein Erling Tysvær
<svein.erling.tysvaer@k...> wrote:

> Is the database that you're converting from a desktop database

(like

> Access or Paradox)? They work nicely on tables, as opposed to

datasets

> which Firebird and other client/server databases prefer. Firebird
> requires a different mindset than desktop databases, and until it
> clicks, you'll be fighting Firebird rather than enjoying it. I

even

> enjoy the "indexing system" of Firebird as it is today!
>
> For anything but data transfer, I cannot understand why anyone

would

> want to run a statement without a where clause on a million-row

table

> (well, possibly if there were some kind of grouping reducing the
> returned set to a few rows). Myself, I work with medium sized

tables,

> up to about 10 million rows. Occasionally, I request 10000 rows,

but

> that is only when someone will actually go through and examine

every

> one of those rows. Without exception, I only request larger result
> sets for people who want to do further processing themselves in

other

> database or statistical systems.
>
> Besides, three and a half minutes to return rows that people will

use

> months to examine isn't too long in my honest opinion. With 2.1
> million rows, that means 9900 rows per second! And I doubt the
> developers will be tempted to remove the multigenerational
> architecture to make it easier for people not wanting to adopt to

a

> client/server mindset.
>
> Sorry if the above sounds a bit harsh,
> Set
>
> --- In firebird-support@yahoogroups.com, "buppcpp" wrote:
> > 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).