Subject | Re: Some benchmarks about 'Order by' - temporary indexes?... |
---|---|
Author | m_theologos |
Post date | 2006-09-20T16:01:32Z |
--- In Firebird-Architect@yahoogroups.com, Pavel Cisar <pcisar@...>
wrote:
30 records which the DBGrid fetched.
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. For users (at
least for users for which I work) is more important to see the first
recs as fast as possible on their screen. (and also, in most of the
cases, the 'Order by' is correlated with a 'Where' so, anyway the
result set is small already - the navigational trade-off of an index
is much reduced).
Thanks very much for your response,
m. Th.
wrote:
>case,
> m_theologos wrote:
> >
> > I made some benchmarks on some FDBs and I found some interestning
> > results running two sets of commands.
> >
> > 1. Set 1: Select * from <table> order by <field>;
> > 2. Set 2: Create index idx1 on <table>(<field>);
> > Select * from <table> order by <field>;
>
> If you didn't fetched all the records from the query in second
> then your benchmark is pointless. Sort via read in index order isknown
> to be faster to return first row, but slower to return the wholeset
> (from almost the same speed to way way worse, depends on actualdata
> distribution on the disk).1. Yes, I didn't fetch all the records, the program fetched only 20-
>
30 records which the DBGrid fetched.
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. For users (at
least for users for which I work) is more important to see the first
recs as fast as possible on their screen. (and also, in most of the
cases, the 'Order by' is correlated with a 'Where' so, anyway the
result set is small already - the navigational trade-off of an index
is much reduced).
Thanks very much for your response,
m. Th.
> best regards
> Pavel Cisar
> IBPhoenix
>