Thread

Re: [HACKERS] Fwd: Joins and links

Leon <leon@udmnet.ru> — 1999-07-09T13:04:13Z

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.