Re: foundations of relational theory? - some references for the truly starving

From: Costin Cozianu <c_cozianu_at_hotmail.com>
Date: Sun, 26 Oct 2003 21:46:36 -0800
Message-ID: <bnibhg$11vvi4$1_at_ID-152540.news.uni-berlin.de>


Anthony W. Youngman wrote:
> In article <bn7rd0$tul6k$1_at_ID-152540.news.uni-berlin.de>, Costin Cozianu
> <c_cozianu_at_hotmail.com> writes
>

>>>This is sometimes true - although not necessarily. The determining
>>>factor is whether or not the read or update involves a "frame fault".
>>>If no "frame fault" in involved then performance is the same whether
>>>the item being accessed is 15 bytes long or 1500. Performance is also
>>>equal regardless of the number of items on the file or total file
>>>size. It will take no longer to read one 1500 byte item from a 10 gig
>>>file containing 30m items than it would to read a 15 byte item from a
>>>10k file containing 100 items.
>>>
>>
>>BS. Or do you mean you don't write to log files ?

>
> Well, that would slow us down slightly, but it would affect both
> relational and MV
>
>>You also have to count that increasing record size decreases the number of rows 
>>stored in a single page (frame)

>
>
> SO WHAT! Mike said he was retrieving ONE row, at random, from a file.
> Who cares how many rows fit in each frame if you're just looking for
> one.
>
> Oh - and you want the stats? On average, to retrieve any one row, chosen
> at random, you need to read just *1.05* frames either to retrieve the
> row from its primary key, or to know that that primary key doesn't
> exist! The size of the file doesn't enter into the equation.
>
> Cheers,
> Wol

Anthony,

You've got no clue about how modern DBMSes work. None (not even your Pick probably) reads 1.05 frames, 1.05 means 2.

Wake up man, we no longer program for 386. The PICK optimized head movements are practically irrelevant.

Head movements, and other non-sensical measures you come up with are amortized over huge cache accesses. Now if you increase the size of the record, then fewer records fit in a cache page.

And all in all, this totally doesn't matter, get a clue man. You both really sound like an assembly programmer claiming that assembly is so much better because you can write faster programs. The big difference is that an assembly programmer has a valid fact, but not a valid claim, you have neither.

As far as performance is concerned, I can assure you that I can run a bank on my laptop these days.

You already wasted so much bandwith with all kinds of non-sesne both you and Mike, so either you get some concrete facts to back you up rather than your amateurish head movements Math, or we should all give up on this thread.

Cheers,
Costin Received on Mon Oct 27 2003 - 06:46:36 CET

Original text of this message