Re: range remove in BTree, or other table storage

On Feb 24, 8:09 am, "Cimode" <cim..._at_hotmail.com> wrote:
> On 24 fév, 01:40, paul c <toledobythe..._at_oohay.ac> wrote:
>
>
>
> > Marshall wrote:
> > > On Feb 23, 12:54 pm, "Cimode" <cim..._at_hotmail.com> wrote:
>
> > >>On 23 fév, 19:54, "laurent" <laurento..._at_gmail.com> wrote:
>
> > >>>Certainly reading books in an excellent method of education,
> > >>>but I disagree that there is no educational value in using the
> > >>>internet.
>
> > >>Disagree with whom ?
>
> > > With the guy who said "you will not get a serious database education
> > > by using google or online questions". It was in the context of
> > > my message but you snipped it.
>
> > > Marshall
>
> > just to get back on the topic, first, i don't have references but could
> > care less about them when talking to somebody who's programmed a btree
> > but I would think when applied to some level in the "tree" the removal
> > of a very definite range should be very fast provided that the free list
> > "underneath" it, if you will, is also physically organized with the same
> > kind of structure as the tree itself.
>
> > as far as physical IO's are concerned, only the nodes at the highest
> > levels would have to change.
>
> > bulk insert is another question. so is postponing the physical,
> > conventional approaches for that would seem to require other components
> > not to do with indexes, such as storage or concurrency managers.
>
> > it all reminds me of auto carburetors for some reason i can't explain
> > very well. separate circuits whose performance effects overlap at
> > certain engine speeds.
>
> > p
>
> Btrees are just a modern reeminiscence of good old VSAM (OS390)
> hierachical search accelerators indexing schemes. As all procedural
> approaches they are inherently underoptimized by breaking rule of
> independence between logical and physical. Their usage is at best
> application specific for pulling out quiclky insert records...Anything
> else added is superfluous. The fact that BULK INSERT is not practical
> to do is a proof of what I say...(As BULK INSERTS were impractical
> under VSAM).

i think you made your point that you do not like b-trees, but sofar you have not suggested an alternative. do you know of one? Received on Sun Feb 25 2007 - 04:38:45 CET