Re: [boost] RTL: Relational Template Library

From: Arkadiy Vertleyb (vertleyb_at_[hidden])
Date: 2005-10-05 17:27:55

"Calum Grant" <calum_at_[hidden]> wrote

> > The RTL was discussed on this list at some time in the past.
> > The early version of RTL is described in the March 2004 issue
> > of CUJ.  The main difference from currently discussed RML is
> > that we decided against using SQL - like interface, and use
> > the relational algebra-based interface instead.
> >
> > This choice is caused by our belief that the optimizer -- the
> > module converting SQL query into an optimized relational
> > expression -- is one of the most sophisticated parts of
> > modern database engines.  Also, writing a good optimizer in a
> > system like RTL (or RML) would have to be done in large part
> > at compile time, by the means of template meta-programming.
> > This task doesn't seems to be feasible, at least currently.
> >
> > OTOH, writing a primitive optimizer, would, in our opinion do
> > more harm than good.
>
> By "harm" do you mean have worse performance?

Yes, and also (possibly) inability to handle more complicated cases.

> If you're going to make claims about the performance of an approach,
> then you need to have benchmarks.  You can't argue about air.  For
> example the RML benchmarks
>
> http://visula.org/relational/benchmarks.html
>
> show RML to be matching or outperforming std::map.
>
> Would you care to benchmark your RTL versus RML or the STL before making
> such claims?  I think that would settle which approach did more "harm".

Note that I didn't say RML's approach is harmful.  All I said is that a
simplistic approach to implementing optimizer is IMO inacceptable.  Are you
saying your optimizer is simplistic? :-)

I believe that talks about performance are premature.  I think it's time to
talk about what can and what can't be done with this libraries.  Then comes
the optimization.

As for benchmarks, for such simple case as yours, you don't need RTL -- you
can benchmark sorted std::vector or Boost.Multi_index.  The performance of
RTL will not be different, since it's based on these containers.  To
outperform STL is definitely not one of RTL's tasks.

For more complicated cases though, such as ones that I described in my
original post, RTL does provide an efficient, index-based solution, while
other libraries, AFAIK, don't.

Regards,
Arkadiy