I'm just slightly bothered by the fact that in all this discussion of hash indexes, I've yet to read any messages describing a
real-world use-case where they're a better solution than the alternatives. Maybe I missed a message here or there covering
that, but I'm still baffled as to why you'd want to send a big blob over the wire to the engine, so the engine can do a hash or
CRC or whatever on it, decide it's a duplicate, and then do what? Raise a key violation and reject the insert? As Jim stated in
a prior message, if you want to do something about the duplication, there will need to be code involved. So how does automating
the creation of the hash simplify this?

As far as multiple index types and storage engines, people who like that stuff already have MySQL available. Those of us who
choose Firebird instead LIKE the fact that it's only 3MB and reasonably simple - both to understand and presumably, test and
debug. Extending it with marginally useful functionality that increases the number of ways things can go wrong wouldn't be an
improvement for most of us.

I'd much rather see the focus remain on the things marked "High" on the roadmap- Asynchronous statement cancellation,
monitoring, in-database user management, temporary tables, SMP support, cross-database queries, etc. We (DRB Systems) are even
willing to increase our sponsorship to help fund some of these things- all of which I can think of real-world use-cases for
(that apply to our use of Firebird.)


-----Original Message-----
From: Firebird-Architect@yahoogroups.com [mailto:Firebird-Architect@yahoogroups.com] On Behalf Of Jim Starkey
Sent: Tuesday, July 11, 2006 09:58 AM
To: Firebird-Architect@yahoogroups.com
Subject: Re: [Firebird-Architect] Indexes and engines



Lars Dybdahl wrote:

> I don't think there is real disagreement on whether it makes sense to use
> hash indexes or not - we're basically just discussing where to put the
> feature.
>
> Right now, there's basically one storage engine and one index type.
>
> However, there's demand for multiple storage engines, with each their index
> types, and the ability to select engine type for each database table:
>
>

Multiple storages engines are a very mixed blessing. Yes, you can get
some efficiencies with downgraded semantics, but the headache of
maintaining consistent semantics across a set of necessarily
incompatible storage engine is close to overwhelming. I would also need
a great deal of convincing that there actually is significant merit to
alternative index types. I wouldn't be so rash as to suggest that there
can't be a better alternative to btree indexes, but btree indexes have
really met the standard of time, giving excellent balance between
performance and simplicity. On the larger question of storage engines,
may I remind you that problem of an appropriate storage engine API is
still unsolved?

--

Jim Starkey
978 526-1376







[Non-text portions of this message have been removed]