> I'd like to know how and which statistics RedBrick uses to decide the
> execution plan.
> In the "Administrator's Guide", in chapter "Tuning a Warehouse for
> Performace", a flow chart diagram is shown.
> There, the join algorithm selection problem is described.
> Well, I'm working with a star schema.
> When I submit a query with one Fact Table and more than one Dimension
> Table without any selection clause, I can't understand, for example,
> how the optimizer selects the order of the DTs for the join with the
> FT. I'm afraid that simply it reflects the order in which I put them
> in the FROM clause.
What do you mean "without any selection clause"? Do you mean "without
a 'where' clause"? I wouldn't use "natural" joins, as I wouldn't
trust them to behave the same way from one major revision to the next.
RedBrick already changed that behavior once between either 2.0 -> 3.0
or 3.0 -> 4.0 (I can't remember exactly).
In any case, it shouldn't matter. If you have a star index it will use
that, and it won't matter what order you specify the tables. The
way to get performance gains via the database is to create alternate
star indexes, or to create separate target indexes on the individual
key columns of the fact table so that the query compiler can (maybe)
choose the better option. Even then, you can't override its choices.
Yet. You can also segment the first key _dimension_ table so that
the "smart query" will limit which index segments to search through
during a data retrieval. (assuming that your fact indexes are
segmented).
Of course, throwing hardware at it wouldn't hurt either, but that's a
whole separate discussion.
by