Re: Lets get physical
Date: Thu, 15 Jun 2006 18:32:36 GMT
Message-ID: <8Jhkg.59740$mh.46861_at_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 - 20:32:36 CEST