Re: Navigation question
Date: 17 Feb 2007 07:36:24 -0800
On Feb 17, 3:13 am, "Tony D" <tonyisyour..._at_netscape.net> wrote:
> On Feb 17, 1:19 am, "Marshall" <marshall.spi..._at_gmail.com> wrote:
> > 'Tis a theory newsgroup. It's enough that the optimization I describe
> > be implementable; it doesn't need to be actually implemented.
> I don't think you made it clear enough that that part of your post
> contained a significant piece of conjecture. You said :
> > Here's a possible execution scenario:
> then described in real world detail, including caches and disks, how
> Dawn's two queries might be executed. You then said :
> > my approach:
> > 1) The system observes that they are both selects so it can order them
> > at its pleasure. So it picks q2 first because it has contacts loaded in cache.
> which can only, given what you said in your post above, be described
> as significant conjecture. Both Dawn and I took this to mean, in
> context, you knew of some DBMS that would optimize in this way. It
> would also be an awful "proof" of anything, given that the conjecture
> includes another conjecture, namely "it has contacts loaded in cache".
> How do you know ?
> The benefits of set-based processing are such that it doesn't need
> conjectures or imaginings to show. The idea that you "navigate" in an
> SQL database (hierarchical queries excepted, of course) is plain
> wrong, and doesn't need conjectures or imaginings to show.
> [ snippage ]
> > However one could imagine, say, an asynchronous JDBC tag library that
> > would permit this optimization.
> And ? I can imagine lots of things too - the death of SQL or at least
> the removal of 'connect by' and friends; or the elimination of both
> NULL and 3VL; or proper support for user defined types, indexing and
> functions (better than PostgreSQL does it, anyway). I wouldn't use
> those imaginings to prove a point, at least not without significant
> health warnings.
I don't accept the criticism. This is a theory newsgroup, not a products newsgroup. The question was about the relative merits of two approaches to some queries. To show a theoretic difference in the two approaches, it is only necessary to show that they are not equivalent in some possible context. Dawn's approach introduced an order dependency that wasn't there before, is totally superfluous, and that potentially reduces the opportunities for optimization. Do you deny it?
I have the utility of "there exists" on my side; you are demanding a "for all" requirement that does not exist. I can conjecture at will, only constrained by what is possible.
I myself have written ODBC drivers that reorder and batch API calls, as I said. I have also heard that there are DBMSs that will delay execution of a query that will flush substantial portions of cache to allow a window for a further query that could use the cached data. And there are many examples of asynchronous dataflow systems out there that behave as I describe the taglib behaving. If you wish to find a flaw in my "possible execution scenario" then you have to show that it's *not* possible. Showing that it's not possible with Oracle 9i doesn't prove anything.
Marshall Received on Sat Feb 17 2007 - 16:36:24 CET