Hannu Krosing wrote:
> The difference will quickly degrade as more rows are fetched in one
> query and cache misses and disk head movement start rattling your
> disks. The analogy being a man who needs 10 different items from a
> supermarket and takes 10 full round trips from home to buy them.
Frankly, I didn't even consider fetching database from disk. This
slows queries immensely and I wonder if there exist someone who
doesn't keep their entire DB in RAM.
> I think that the two-tables-one-row lookup will gain the most,
> probably even more than 10%
I think the gain will raise with the number of tables, because
the more tables - the more index lookups are saved.
> Adding links does nothing to improve the optimizer, its still free
> to choose sucky plans. It is possible that links are faster if used
> in the right way, as they cut out the index lookup, but I suspect that
> hard-coding link-is-always-faster into the optimiser would also produce
> a lot of very bad plans.
Methinks that hard-wiring link-is-always-faster into optimizer will
still help it very much, because there are few situations where it
is not true.
> Fixing the optimizer would get a performance gain on a far wider
> range of tasks, and is still needed for links.
But general fixing of optimizer is total rewritement of it, whereas
link fix is almost a fast hack.
> So I quess thet if you want links in foreseeable future, your best bet
> would be to start coding, and to coordinate with whoever starts to
> fix/rewrite
> the optimizer (probably Vadim)
>
Unfortunately I already have a project to work on. There is too
little of me for two projects.
--
Leon.