Re: Informix vs. Sybase vs. Oracle vs. (gasp) MS SQL Server
Date: 1997/12/08
Message-ID: <66ge6a$l9i_at_rocky.carmenta.se>
In article <34876AAC.1FF7_at_agd.nsw.gov.au>, no_sp.am_at_agd.nsw.gov.au says...
>
>Johan Andersson wrote:
>>
>> No. My point was that specific databases was not the issue.
> I thought that this is what I've been trying to say,
> irrespective of what others have been claiming?
>
Right, and we agree. We discuss the relevance of RLL.
>> > And increasing concurrency gives you ... ?
>> Faster response times to the users, for example.
> And not increased contention for resources as well?
>
Of course, which is why I assume that having as fine a granularity as possible
when locking resources would decrease response times.
>> >> The only thing the TPC-C proves is that there exists at least one
>> >> application for which RLL / PLL is not an issue.
>> >
>> My point was that Pablo has no proof of his statement. I have not tried to
>> prove my assumptions. [...] He waved the
>> TPC-C test as proof, IMHO this is not so, for the above reason.
>
You seem to be contradicting yourself here. Above you stated
that "The only thing the TPC-C proves ..." and immediately above
you now state "IMHO this is not so". Can you clarify your
stance? I'm under the impression that only one proof or
disproof is required.
My point is the difference between proving something for a single member of a set and proving something for all members of a set. The set in this case being 'all OLTP applications'. Pablo stated that RLL is not an issue for _all_ OLTP applications because of the TPC-C test. I stated that the TPC-C test has only proven that RLL is not an issue for _one_ OLTP application.
However, as has been pointed out by some other people in this thread, the TPC-C test probably doesn't even prove the non-issue of RLL for _one_ application. There are to many variables and the TPC-C test is by no means designed to test RLL relevance.
>> >> [.. my description of TPC-C ...]
>> It mimics _one_ OLTP application.
>
> True. but I don't think its possible for it to mimic all.
>
I agree, and my point is that because it doesn't and never tried to, it can
not be used as a proof of a statement regarding 'all'.
>> > I don't know of any OLTP applications that are batch jobs. Do you?
>> >
>> The combination of batch an OLTP is not unexistant, why?
>
> The implication of batch is that it does not require interaction
> where as OLTP would. [...]
>
What I mean by combination is that for a whole system there is typically both
OLTP and batch applications running concurrently.
>
>> Where
>> is your proof that _all_ OLTP applications 'does the same thing over and
>> over'?
>
> I didn't say "all", I said "an".
>
Ok, for any single OLTP application this may very well be true.
> An OLTP application is designed
> to do its task and its task only.
>
This seems suspiciously like a statement of all OLTP applications, in which
case I do not agree.
> True, it may well be more than
> one single specific task. These tasks would be of differing complexity,
> as you note. However, within a single task, I can't see how
> it would ever change the nature of its complexity.
> That is, the task follows the program specification. This may change
> dependant on the conditions (i.e. different conditional tests
> cause different code to be executed), but the overall complexity
> itself can never go beyond the bounds imposed by the code.
>
As soon as you introduce an iteration or a recursive algorithm which depends
on user activity, the complexity becomes unknown at compile time. Even the
maximum complexity becomes unknown. The most simple example that comes to mind
is for the user to input an integer number and the application then inserting
that number of rows in a table, very unrealistic example :-), but it shows
that transaction complexity need not be decided at compile time.
> This matches your point about the complexity being user driven. As
> this was your real point, then yes, the complexity can vary
> based on the dataset. In this case, varying the dataset would
> test an RDBS differently, as was your original comment.
>
Right, and the TPC-C test does not seem to do that. My assumption was that RLL
did not become an issue in the TPC-C because of the very low complexity of the
transactions. This is why I thought it would be interesting to see a test of
transactions with ever increasing complexity, I believe RLL will then become
an issue.
OK, and my point has been that any application that mandates RLL can be modified so as not to require it. I didn't find any of the cited examples adequate. I believe I suggested alternatives for at least two of them.
Correct, the issue is still open. I'll see if I can cook up an example of an 'RLL needing' application...
/Johan
| >>> The opinions herein are mine and not neccessarily my employers <<< |
| Johan Andersson, Msc CSE jna_at_carmenta.se | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Received on Mon Dec 08 1997 - 00:00:00 CET