Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: Lets get physical

Re: Lets get physical

From: Cimode <cimode_at_hotmail.com>
Date: 15 Jun 2006 11:07:54 -0700
Message-ID: <1150394874.138828.244950@i40g2000cwc.googlegroups.com>

paul c wrote:
> Like some others here (as best as I can recall), I've puzzled over
> comments such as the TRM not being a physical layer.

Anybody who stated has not a clue about RM...What a stupid comment...who advocated that? I certainly did'nt...

Also, I noticed
> recently that the last of the LZW patents is about to expire. Not that
> they're related but along with the latest jibe about physical matters,
> it gets me to thinking about implementations again.

>From reading the patents information and observation, I have not found
anything related to hardware issues and their impact on implementation.  Only algoryhtmics explanations about representation and operations have been exposed to the public...

> I can accept the assertion about TRM as being a kind of indirection as
> long as I can envisage direct structures and algorithms for implementing
> it. TRM's ideas may well go deeper than I can express but what stuck
> with me about trying to implement it is that as far as deleting and
> insert are concerned the nature of OS storage allocation, whether on
> disk or in ram is such that lots of pointer chasing or re-allocation
> seems to be needed, if one avoids a "row-image" mapping. (When I say
> pointers, I don't necessarily mean the familiar 32 or 64 bit ones.)
The problem is much more complex then simple mapping. It's about faitful physical representation of a multidimensional relvars when limits are imposed by current computing scheme involving

> In blunt terms, I couldn't see how a physical implementation of TRM
> could avoid having two values for some equivalent of pointers for each
> "row-column intersection", one to associate a value within a "row" or
> "tuple" and another to place it within some ordering. Not counting the
> values themselves, all those pointers seem to me to result in a physical
> size that is probably similar to one that used, say, a btree index for
> every column of a row-image table.

That's my point...Anyway you turn it, physical implementation limit the representation of a relvar...
Indexes are a secondary irrelevant issue. Building a better relational DBMS supposes you just ignore that concept...

Whether the indexes are sparse or
> dense or whether they have shortcuts to avoid repeating identical values
> seemed irrelevant as far as comparing a TRM implementation with say, a
> so-called column-based store.
>
> What I read about TRM seemed to echo my impression, if only because of
> the two logical structures it gives.
>
> At the level or disk or ram, it seems to me that for a db of
> unpredictable size the usual fragmentation wastage will arise. (Also,
> depending on the number of columns, insert and delete time could be
> quite lengthy for an implementation that tries to minimize storage.)
>
> Finally, I wonder whether anybody has thought of implanting an LZW or
> other compression variation in conventional indexes
.
A true relational DBMS has not indexes. Just ignore them. You think too much in function of the SQL implementation and not enough in function of RM?

> Whether TRM is fundamentally a new idea or not doesn't seem to be a
> question that its proponents are going to give us an answer for. If
> somebody could show that at a physical level, it has no overriding
> advantages, I think that would be useful as I suspect there are others
> besides me for whom it would save time. Of course if somebody could
> show the opposite, that might be even more useful.

TRM has brought some interesting insights on programmatics of representation but not sufficiently about physical architecture prerequisites. He has not dealt to the relatonship between programmatic handling of datum and its efficiency on computing architecture (CPU to RAM to Disk). Maybe these should be reconsidered first...  

> p
Received on Thu Jun 15 2006 - 13:07:54 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US