Bruce Momjian wrote:
>
> > I was originally thinking that this would be supported like the btree
> > indexes are now -- an index on (a,b,c,d) serves as in index on a,
> > (a,b), (a,b,c) and (a,b,c,d), but it doesn't serve as an index on b,
> > or (b,c), etc. My original idea was that the first item in the index
> > would define a hash table whose entries were hash tables on the second
> > item, etc. I now think that this would waste quite a bit of space,
> > and would have the same restriction as btrees, which is unnatural.
>
> This is a standard restriction. If you need an index on a lower-level
> field, create one. I don't think you are going to be able to improve on
> (a,b), (a,b,c). If you allowed (b,c) that is another index.
What I meant is that this is a perfectly reasonable restriction for
btree indexes. If the index is built on (a,b,c,d), then finding the
nodes where a=5 gives you a few branches of the tree, and if you
further restrict this to b=10, then you need only look at these
branches. The same could be said for ranges of a values.
Hash tables are different in that they do not have this tree structure
(unless we impose this structure on them. The problem I see with
building this tree structure as I described earlier is that it has the
possibility for a lot of wasted space (even more than btrees). Also,
if we can provide the added functionality that a hash index on (a,b)
is also an index on b, with equal or lesser memory usage than the
hash-tree, wouldn't this be a "good thing".
Anyway, I think this needs some thinking. I will look at the
alternatives and post something a bit later.
Ocie
