--- In Firebird-Architect@yahoogroups.com, Pavel Cisar <pcisar@...>
wrote:

>
> m_theologos wrote:
> >
> > 2. IMHO, I didn't think that the benchmark is pointless because

in

> > the real world, on the client side, there are very rare the cases

in

> > which someone wants to 'see' the entire set. Now I don't imagine
> > someone which wants to browse let's say 20000 recs.
>
> True, but not all applications are "interactive browsers". If you

want

> such optimization, then define required indices. Server has no
> information what's preferred behavior for you, so it's pointless to
> complicate the server's code to give you "optimizations" you don't

want

> and that in fact would hurt performance in some cases. Anyway, your
> proposal to build temporary indices on the fly is flawed, as it

might

> work only for simple queries from single table.
>

I don't meant the use of the indices as they are, but I saw the fact
that the indices help. (After further investigations I saw that the
gain is bigger if the table is wider). So, perhaps, if you'll sort
only the keys (not the entire records) the things will be faster.
Also, the indices, in the form in which they are today have also more
shortcomings: the user cannot index(read: sort) blobs, computed
columns, throws 'object in use' when others are on that table, so is
out of question to use the code in the actual form. I meant to use
only the ideea of sorting the key what is needed. Do you think that
it wouldnt help? (Unfortunatelly I don't have time to look in the
code...)

All best wishes,

m. Th.

> best regards
> Pavel Cisar
> IBPhoenix
>