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: J M Davitt <jdavitt_at_aeneas.net>
Date: Thu, 15 Jun 2006 18:32:36 GMT
Message-ID: <8Jhkg.59740$mh.46861@tornado.ohiordc.rr.com>


Cimode wrote:

> 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...

Are you referring to the TRM patent or the LZW patent?

>>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

"...involving" what?

>>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?

Who? paul? paul is thinking of SQL implementations?

>>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...

Okay, I'll bite: what are "programmatics of representation?"

>
>>p
Received on Thu Jun 15 2006 - 13:32:36 CDT

Original text of this message

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