Re: Self Joins and optimization

From: David Cressey <cressey73_at_verizon.net>
Date: Wed, 09 May 2007 13:00:10 GMT
Message-ID: <uBj0i.14554$rm.10970_at_trndny03>


"Brian Selzer" <brian_at_selzer-software.com> wrote in message news:U0x%h.316$y_7.72_at_newssvr27.news.prodigy.net...
>
> "Brian Selzer" <brian_at_selzer-software.com> wrote in message
> news:JBe%h.16839$YL5.304_at_newssvr29.news.prodigy.net...
> >
> > "David Cressey" <cressey73_at_verizon.net> wrote in message
> > news:Vg5%h.166$83.81_at_trndny08...
> >>
> >> "Brian Selzer" <brian_at_selzer-software.com> wrote in message
> >> news:MQ2%h.4456$H_.2052_at_newssvr21.news.prodigy.net...
> >>>
> >>> "David Cressey" <cressey73_at_verizon.net> wrote in message
> >>> news:ZE%_h.163$D52.68_at_trndny04...
> >>> > In the "interpolation" thread, Brian has been expounding on the
idea
> >> that
> >>> > he can discover algorithms that he knows to be correct, and that
> >>> > outperform
> >>> > anything an optimizer can generate. He's mentioned "self joins" and
> >>> > the
> >>> > idea that he can get a job doen with only one read, where the
> >>> > automatic
> >>> > solution generated in response to declarative code generates
multiple
> >>> > passes
> >>> > through the data.
> >>> >
> >>> > My experience leads me to the opposite conclusion from that.
> >>> >
> >>> > Here's the questions I'd like the newsgroup to consider:
> >>> >
> >>> > What, if any, algorithms that are demonstrably correct are going to
be
> >>> > overlooked by the optimizer, although discoverable by a human
coder?
> >> Why
> >>> > would an optimizer fail to discover the possibility of eliminating
> >>> > self-joins? Are there any undecidability issues here?
> >>> >
> >>> Here's a maybe not-so-simple example:
> >>>
> >>> Given a table with the columns,
> >>>
> >>> EMPLOYEE#, JOB#, STEP#, MACHINE#, TX_TIME, TX_TYPE
> >>>
> >>> where TX_TYPE can be either 'ON' or 'OFF' and the key is the entire
> >> heading,
> >>>
[Big snip]

Brian,

I'm not ignoring your example. I'm trying to digest it, a little bit at a time. As you said, it's not quite so simple. I have no response at this time, other than vague philosophical generalities. I think it would be insulting to offer such generalities in response to your input of code and data.

So I'm hoping, before too long, to have something more specific to say.

In the meantime, your example provides me much food for thought about temporal data, transition versus state, and simultaneity. Received on Wed May 09 2007 - 15:00:10 CEST

Original text of this message