Re: Concurrency in an RDB

From: David <davidbl_at_iinet.net.au>
Date: 27 Dec 2006 15:04:09 -0800
Message-ID: <1167260649.030858.105350_at_n51g2000cwc.googlegroups.com>


paul c wrote:
> David wrote:
> > paul c wrote:
> >
> >>David wrote:
> >>...
> >>
> >>>Despite the logical purity there are disadvantages to be considered.
> >>>Modern CPUs are quite adept at manipulating strings in the normal
> >>>representation. The space and time overheads of your suggestion are
> >>>significant.
> >>>...
> >>
> >>Actually relatively less adept than they used to be, ie., the
> >>instruction sets have stagnated for decades and when applied to a
> >>sequential string incur all kinds of cache misses on the latest cpu's
> >>which are so much faster than the memory they use, ie., they don't come
> >>close to the advertised cpu speed.
> >
> >
> > Nevertheless I wouldn't be surprised if the string manipulation is 100
> > times slower with the relational approach. Each step through a
> > head-tail list would typically involve an independent search through a
> > BTree.
> >
> > David
> >
>
> What is the point of such a notion? - is it just a strawman? What
> possible reason would one have to apply relational operators to strings,
> at least strings as most humans would read or write them? What is
> inherent in an arbitrary string that would benefit from the
> organizational or inferencing abilities of the RM?
>
> If this is a strawman, what is the real point?

In an earlier post I stated that in a DB used to store the content of a newspaper I wouldn't store the actual text relationally. Marshall suggested that RM was in fact suitable and gave the example of the head-tail list to store the individual characters. I disagree because it isn't practical (and as you say, not particularly useful either).

Cheers,
David Received on Thu Dec 28 2006 - 00:04:09 CET

Original text of this message