Subject Re: Some benchmarks about 'Order by' - temporary indexes?...
Author m_theologos
--- In, Pavel Cisar <pcisar@...>
> m_theologos wrote:
> >
> > 2. IMHO, I didn't think that the benchmark is pointless because
> > the real world, on the client side, there are very rare the cases
> > 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
> 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
> and that in fact would hurt performance in some cases. Anyway, your
> proposal to build temporary indices on the fly is flawed, as it
> 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

All best wishes,

m. Th.

> best regards
> Pavel Cisar
> IBPhoenix