Subject | Re: [firebird-support] Large record count - will it work? |
---|---|
Author | Kjell Rilbe |
Post date | 2009-02-18T08:18:09Z |
Thomas Steinmaurer wrote:
data, but as far as I know, you cannot change the SQL that IS
autogenerated. But it *might* be possible. ECO is very powerful in many
ways and I think this is one of them...
Anyway, regarding the problem I've most often stumbled upon: correlated
subqueries, I'd think that FB could be improved to perform better. If I
understand correctly the current approach is to execute the subquery
once for each "master" record. Obviously very inefficient if the
subquery can't use an index.
But in theory, FB could start by building a list of "link values" and
then execute the subquery once, retrieving all matching records at once,
and then merge into the "master" result set.
In theory, but can it be done "easily" in the FB engine?
Kjell
--
--------------------------------------
Kjell Rilbe
DataDIA AB
E-post: kjell@...
Telefon: 08-761 06 55
Mobil: 0733-44 24 64
> > Aage Johansen wrote:I believe ECO lets you use whatever custom SQL you want to retrieve
> >> If ECO generates Firebird-unfriendly SQL you may find yourself in a
> >> position where you cannot really fine tune the queries. This may be
> >> the case for any db system, and I don't know ECO at all. Just a
> >> faint recollection of someone having problems with generated SQL
> >> which were not optimized well (don't remember which db server).
> >
> > If that happens I hope the ECO people will try to generate better SQL or
> > at least help me inject special SQL where needed.
>
> This is in fact a general problem with OR mappers (although ECO isn't an
> OR mapper only) that the generated SQL isn't always optimal. ;-)
data, but as far as I know, you cannot change the SQL that IS
autogenerated. But it *might* be possible. ECO is very powerful in many
ways and I think this is one of them...
Anyway, regarding the problem I've most often stumbled upon: correlated
subqueries, I'd think that FB could be improved to perform better. If I
understand correctly the current approach is to execute the subquery
once for each "master" record. Obviously very inefficient if the
subquery can't use an index.
But in theory, FB could start by building a list of "link values" and
then execute the subquery once, retrieving all matching records at once,
and then merge into the "master" result set.
In theory, but can it be done "easily" in the FB engine?
Kjell
--
--------------------------------------
Kjell Rilbe
DataDIA AB
E-post: kjell@...
Telefon: 08-761 06 55
Mobil: 0733-44 24 64