Re: Implementation of Grid File
Date: Sat, 4 Jan 2003 10:30:29 +1000
Message-ID: <kOpR9.16077$jM5.44303_at_newsfeeds.bigpond.com>
> I was
> considering B-Tree's however, that would require 24 in total (4*3*2*1), as
> any mix of columns could be used for the seed of the query (C&D, B&C).
If order does not matter (ie. a query involving C & D is equivalent to D & C) then you've only got 15 in total.
And if, as you said in a previous posting, there is a maximum of two query columns (and order does not matter), there's only 10 indexes.
And if you're using B-trees, you can do with just 6. Consider these indexes:
ABCD, ACD, BCD, DA, BD, CD
> The reason I was considering the implementation of Grid file is that it
Since order doesn't matter and we're considering B-trees, you can use ABCD
for a query on A, AB, BA, ABC, ACB, BCA, BAC or ABCD.
(ie. any permutation of a prefix of an index).
has
> two disc access, which would be efficient for the application.
>
> So what about a happy median? a multi-dimensional data structure with
> efficient disk access? Could R-Tree be used in such a way
A kd-tree might be appropriate.
Alternately, I have the feeling you've got few enough rows to be able to use a couple of smaller B-tree or hash indexes (say just A,B,C,D and maybe even some composite indexes) and filter, in memory, the result of a less specific query.