Re: In an RDBMS, what does "Data" mean?
From: Eric Kaun <ekaun_at_yahoo.com>
Date: Thu, 10 Jun 2004 20:23:06 GMT
Message-ID: <Kq3yc.2602$1v6.1860_at_newssvr15.news.prodigy.com>
> In message <AwJxc.378$Pt.303_at_newssvr19.news.prodigy.com>, Eric Kaun
> <ekaun_at_yahoo.com> writes
> >"Anthony W. Youngman" <wol_at_thewolery.demon.co.uk> wrote in message
> >news:LnpFiHNqXPxAFwgC_at_thewolery.demon.co.uk...
> >> In message <kH4wc.5267$n65.660_at_newssvr33.news.prodigy.com>, Eric Kaun
> >> <ekaun_at_yahoo.com> writes
> >
> >> relational actually
> >> prevents you from even trying to prove the question is easy, merely
> >> saying "you have no choice but to trust the optimiser" :-(
> >
> >Huh? Prove the question is easy? What does that mean?
> >
> >At any level above hardware, we have no choice - it depends on the
> >processor, and hard disk, and memory speed, and... so of course there's a
> >level of trust involved. Do you trust the Pick compiler / interpreter? I
> >certainly want to delegate the nasty business of optimization (which
we've
> >demonstrated is useful in the considerably more-difficult area of
compilers)
> >to a machine which can do the job better and faster than I.
> >
> Basically, if we assume (reasonable assumption) that everything else is
> irrelevant when compared to disk access, I can prove that (almost) every
> attempted disk access actually retrieves data that is relevant to the
> question.
Date: Thu, 10 Jun 2004 20:23:06 GMT
Message-ID: <Kq3yc.2602$1v6.1860_at_newssvr15.news.prodigy.com>
"Anthony W. Youngman" <wol_at_thewolery.demon.co.uk> wrote in message news:S02zW8QUQ7xAFwCE_at_thewolery.demon.co.uk...
> In message <AwJxc.378$Pt.303_at_newssvr19.news.prodigy.com>, Eric Kaun
> <ekaun_at_yahoo.com> writes
> >"Anthony W. Youngman" <wol_at_thewolery.demon.co.uk> wrote in message
> >news:LnpFiHNqXPxAFwgC_at_thewolery.demon.co.uk...
> >> In message <kH4wc.5267$n65.660_at_newssvr33.news.prodigy.com>, Eric Kaun
> >> <ekaun_at_yahoo.com> writes
> >
> >> relational actually
> >> prevents you from even trying to prove the question is easy, merely
> >> saying "you have no choice but to trust the optimiser" :-(
> >
> >Huh? Prove the question is easy? What does that mean?
> >
> >At any level above hardware, we have no choice - it depends on the
> >processor, and hard disk, and memory speed, and... so of course there's a
> >level of trust involved. Do you trust the Pick compiler / interpreter? I
> >certainly want to delegate the nasty business of optimization (which
we've
> >demonstrated is useful in the considerably more-difficult area of
compilers)
> >to a machine which can do the job better and faster than I.
> >
> Basically, if we assume (reasonable assumption) that everything else is
> irrelevant when compared to disk access, I can prove that (almost) every
> attempted disk access actually retrieves data that is relevant to the
> question.
Oh... easy == fast.
Perhaps the above is true, but that requires your data be structured in the same file, which is both boon and bane. In a TRDBMS (remember, this is c.d.t), the DBMS would reorganize base relations's storage based on access patterns, whereas in Pick you have to decide that in advance, and do a lot of work later if it changes. Unless I'm misinterpreting... in any event, access optimization and clustering based on common usage (which can change, especially as reports and ad hoc queries enter the fray) should be dynamic, and analyzed by a computer.
- erk