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: range remove in BTree, or other table storage

Re: range remove in BTree, or other table storage

From: Cimode <cimode_at_hotmail.com>
Date: 24 Feb 2007 05:09:50 -0800
Message-ID: <1172322589.994799.94440@h3g2000cwc.googlegroups.com>


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). Received on Sat Feb 24 2007 - 07:09:50 CST

Original text of this message

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