Re: Navigation question

From: Bob Badour <>
Date: Sat, 17 Feb 2007 15:50:12 GMT
Message-ID: <UuFBh.7588$>

Marshall wrote:

> On Feb 17, 3:13 am, "Tony D" <> wrote:

>>On Feb 17, 1:19 am, "Marshall" <> 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.
> Tony,
> 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 and Tony, I sympathize with both views, which is why I mentioned Date's _Principle of Incoherence_.

Marshall, yes this is a theory newsgroup. Yes, Dawn introduced an order dependency. No, your argument did not sound coherent in reply to her nonsense.

What Tony recommends would have required you to stop and explain some rather obvious points and would have held you to a higher standard than the self-aggrandizing ignorants. For the coherence of your reply to shine through, you would have to go to that extra effort. And if you did go to the extra effort, the eyes of the people who stand to benefit the most would glaze over and they would move on without reading.

Finally, the shit-disturbing moron has the two of you arguing. Please find some way to ignore her. She distracts you and disturbs the peace of the forum. Received on Sat Feb 17 2007 - 16:50:12 CET

Original text of this message